You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Cooke, Mark" <ma...@siemens.com> on 2013/12/04 13:00:41 UTC
Why does `svnversion -c` give me a range?
Hi Folks,
I would like to include the svn revision number in my project's version info but I am confused by the results of svnversion. I want the version number of a tagged tree to always be the same (i.e. the last commit to the tag) but if the tag is to be rebuilt using a fresh checkout some time later `svnversion` seems to report the HEAD revision. So I looked at `svnversion -c` but this always seems to give me a range e.g. `2:1476`, even directly after an update.
I have read the red book but it is quite vague about the -c option. Why is `-c` always giving me a range?
Many thanks,
~ mark c
RE: Why does `svnversion -c` give me a range?
Posted by "Cooke, Mark" <ma...@siemens.com>.
> -----Original Message-----
> From: Ryan Schmidt [mailto:subversion-2012c@ryandesign.com]
> Sent: 05 December 2013 09:29
>
> On Dec 5, 2013, at 03:23, Cooke, Mark wrote:
>
> >> Note that "bare" svnversion can give a range as well:
> >>
> >> % svnversion -c ~srv/conf
> >> 105:143
> >> % svnversion ~srv/conf
> >> 142:143
> >
> > Understood, however for my example I get a different "sort"
> > of answer with(out) `-c` on all my WCs (including an
> > unmodified fresh checkout), without `-c` gave a single
> > revision, with `-c` always gives a range. That seems to me
> > to be inconsistent (even wrong):
>
> The output makes sense to me:
>
> > {{{
> > D:\PROJECTS\Support\Code>svn --version
> > svn, version 1.7.10 (r1485443)
> > compiled Jun 1 2013, 07:40:50
> > <snip>
> >
> > D:\PROJECTS\Support\Code>svn up .
> > Updating '.':
> > At revision 638.
> >
> > D:\PROJECTS\Support\Code>svnversion .
> > 638
>
> This means that all the items in this working copy are "at"
> revision 638, i.e. you ran "svn up -r 638" (or just "svn up"
> if 638 is the HEAD revision). It means this is not a
> mixed-revision working copy, and that none of the items were
> in a modified state, which can be good to know.
>
>
> > D:\PROJECTS\Support\Code>svnversion . -c
> > 235:635
> > }}}
>
> This means the least recently changed item in this working
> copy was changed in revision 235 and the most recently
> changed item was changed in revision 635.
Ok, I agree that makes sense (and is even consistent with an interpretation of the help text). But is it what a user would want to know? I wanted just the most recent committed version, I wonder if that is too specific? ...I can get it by parsing the output using `-c`. What would you ever want to know the earliest commited revision for?
Basically, `-c` will always give you a range as soon as any file has been added/modified/deleted after the initial commit.
Seeing as this is long established output I would not propose changing the output of `-c`. I think (a) the help text could be expanded for the `-c` option and (b) a new option for just the "most recent commit" would be useful. Both should still use the `MSP` postfixes too.
A) the current behaviour contradicts the headling "single number for fully updated WC" description:
{{{
Note that the -c option will almost always return a range, it is a rare working copy to have had only one commit or to update all files at the same time.
}}}
B) useful for adding this WC's most-recent-commit revision to version info:
{{{
-m [--most-recent-commit] : report the most recent change revision only
}}}
Does anyone agree? Is this worth a ticket?
~ mark c
Re: Why does `svnversion -c` give me a range?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 5, 2013, at 03:23, Cooke, Mark wrote:
>> Note that "bare" svnversion can give a range as well:
>>
>> % svnversion -c ~srv/conf
>> 105:143
>> % svnversion ~srv/conf
>> 142:143
>
> Understood, however for my example I get a different "sort" of answer with(out) `-c` on all my WCs (including an unmodified fresh checkout), without `-c` gave a single revision, with `-c` always gives a range. That seems to me to be inconsistent (even wrong):
The output makes sense to me:
> {{{
> D:\PROJECTS\Support\Code>svn --version
> svn, version 1.7.10 (r1485443)
> compiled Jun 1 2013, 07:40:50
> <snip>
>
> D:\PROJECTS\Support\Code>svn up .
> Updating '.':
> At revision 638.
>
> D:\PROJECTS\Support\Code>svnversion .
> 638
This means that all the items in this working copy are “at” revision 638, i.e. you ran “svn up -r 638” (or just “svn up” if 638 is the HEAD revision). It means this is not a mixed-revision working copy, and that none of the items were in a modified state, which can be good to know.
> D:\PROJECTS\Support\Code>svnversion . -c
> 235:635
> }}}
This means the least recently changed item in this working copy was changed in revision 235 and the most recently changed item was changed in revision 635.
RE: Why does `svnversion -c` give me a range?
Posted by "Cooke, Mark" <ma...@siemens.com>.
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: 04 December 2013 16:08
>
> Ryan Schmidt wrote on Wed, Dec 04, 2013 at 06:14:33 -0600:
> >
> > On Dec 4, 2013, at 06:00, Cooke, Mark wrote:
> >
> > > I would like to include the svn revision number in my
> project's version info but I am confused by the results of
> svnversion. I want the version number of a tagged tree to
> always be the same (i.e. the last commit to the tag) but if
> the tag is to be rebuilt using a fresh checkout some time
> later `svnversion` seems to report the HEAD revision. So I
> looked at `svnversion -c` but this always seems to give me a
> range e.g. `2:1476`, even directly after an update.
> > >
> > > I have read the red book but it is quite vague about the
> -c option. Why is `-c` always giving me a range?
> >
> > I think the `-c` option means: given all the item in this
> directory and recursive subdirectories, give the oldest and
> newest changed file. So, the oldest item in your working copy
> was last changed in revision 2, and the newest was last
> changed in revision 1476.
> >
> > And `svnversion` without any flag does seem to give the latest
> > revision to which the working copy was updated, not the last changed
> > revision.
> >
>
> Note that "bare" svnversion can give a range as well:
>
> % svnversion -c ~srv/conf
> 105:143
> % svnversion ~srv/conf
> 142:143
Understood, however for my example I get a different "sort" of answer with(out) `-c` on all my WCs (including an unmodified fresh checkout), without `-c` gave a single revision, with `-c` always gives a range. That seems to me to be inconsistent (even wrong):
{{{
D:\PROJECTS\Support\Code>svn --version
svn, version 1.7.10 (r1485443)
compiled Jun 1 2013, 07:40:50
<snip>
D:\PROJECTS\Support\Code>svn up .
Updating '.':
At revision 638.
D:\PROJECTS\Support\Code>svnversion .
638
D:\PROJECTS\Support\Code>svnversion . -c
235:635
}}}
> FWIW, all this should be documented in 'svnversion --help'.
> Is it clear there?
As I mentioned, the help text would lead me to expect a consistent style of results, hence the question. The only mention of `-c` is:-
{{{
-c [--committed] : last changed rather than current revisions
}}}
Combined with the main text: "The version number will be a single number if the working copy is single revision, unmodified, not switched and with an URL that matches the TRAIL_URL argument." I would also expect a single number using `-c`.
However, I am exclusively on windoze so tsvn's SubWCRev app is ideal for what I want.
~ mark c
> > If you want the last changed revision, you could use:
> >
> > svn info | sed -n 's/^Last Changed Rev: //p'
Re: Why does `svnversion -c` give me a range?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Wed, Dec 04, 2013 at 06:14:33 -0600:
>
> On Dec 4, 2013, at 06:00, Cooke, Mark wrote:
>
> > I would like to include the svn revision number in my project's version info but I am confused by the results of svnversion. I want the version number of a tagged tree to always be the same (i.e. the last commit to the tag) but if the tag is to be rebuilt using a fresh checkout some time later `svnversion` seems to report the HEAD revision. So I looked at `svnversion -c` but this always seems to give me a range e.g. `2:1476`, even directly after an update.
> >
> > I have read the red book but it is quite vague about the -c option. Why is `-c` always giving me a range?
>
> I think the `-c` option means: given all the item in this directory and recursive subdirectories, give the oldest and newest changed file. So, the oldest item in your working copy was last changed in revision 2, and the newest was last changed in revision 1476.
>
> And `svnversion` without any flag does seem to give the latest
> revision to which the working copy was updated, not the last changed
> revision.
>
Note that "bare" svnversion can give a range as well:
% svnversion -c ~srv/conf
105:143
% svnversion ~srv/conf
142:143
FWIW, all this should be documented in 'svnversion --help'. Is it clear
there?
> If you want the last changed revision, you could use:
>
> svn info | sed -n 's/^Last Changed Rev: //p'
>
>
>
Re: Why does `svnversion -c` give me a range?
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Ryan Schmidt wrote on Wed, Dec 04, 2013 at 10:06:02 -0600:
> `svnversion` recursively scans the working copy. `svn info` operates
> on the current directory only.
In case it's not clear: 'svn info' operates on the current directory
*node* only; it's like "stat ./", not like "ls ./".
That is, if ./README is ta r50 and ./ is at r40, 'svn info' will report
r40.
Daniel
Re: Why does `svnversion -c` give me a range?
Posted by Ryan Schmidt <su...@ryandesign.com>.
Remember to Reply All so the discussion stays on the mailing list.
On Dec 4, 2013, at 07:52, Cooke, Mark wrote:
>> -----Original Message-----
>> From: Ryan Schmidt [mailto:subversion-2012c@ryandesign.com]
>> Sent: 04 December 2013 12:15
>>
>> On Dec 4, 2013, at 06:00, Cooke, Mark wrote:
>>
>>> I would like to include the svn revision number in my
>>> project's version info but I am confused by the results of
>>> svnversion. I want the version number of a tagged tree to
>>> always be the same (i.e. the last commit to the tag) but if
>>> the tag is to be rebuilt using a fresh checkout some time
>>> later `svnversion` seems to report the HEAD revision. So I
>>> looked at `svnversion -c` but this always seems to give me a
>>> range e.g. `2:1476`, even directly after an update.
>>>
>>> I have read the red book but it is quite vague about the -c
>>> option. Why is `-c` always giving me a range?
>>
>> I think the `-c` option means: given all the item in this
>> directory and recursive subdirectories, give the oldest and
>> newest changed file. So, the oldest item in your working copy
>> was last changed in revision 2, and the newest was last
>> changed in revision 1476.
>
> You seem to be right but that is not what I understand from the docs. The only reference to the -c option says "Use the last-changed revisions rather than the current (i.e., highest locally available) revisions." which to me means that I should get the similar results as I would expect without using -c. In other words, a fully updated, unmodified WC should give a single revision number and I would expect -c to also give a single revision number (at least that is what I think I want) but it does not:
>
> D:\PROJECT>svn update
> Updating '.':
> At revision 1770.
>
> D:\PROJECT>svnversion .
> 1770M
>
> D:\PROJECT>svnversion . -c
> 2:1764M
>
> ...I tried the same on a fresh checkout of one of our tags and got similar results (without the `M` flag). The book could do with some clarification but I am not certain yet what the definitive answer actually is.
Based on my testing, the `-c` flag “use[s] the last-changed revisions” (of each item) “rather than the current (i.e., highest locally available) revisions” (of each item), as it says.
>>> And `svnversion` without any flag does seem to give the
>>> latest revision to which the working copy was updated, not
>>> the last changed revision.
>>
>> If you want the last changed revision, you could use:
>>
>> svn info | sed -n 's/^Last Changed Rev: //p'
>
> We are not allowed to install unapproved apps <insert sad face here> and sed is not available here (obviously there are similar ways to achieve this but I was hoping to avoid complicating things any more than I have to).
>
> The `Last Changed Date` would also be useful so I guess I'll have to go a scripted svn info route. Oh, hang on, doesn't `svn info` need to be called recursively whereas `svnversion` doesn't?
>
> Thanks for your help,
>
> ~ mark c
`svnversion` recursively scans the working copy. `svn info` operates on the current directory only.
Re: Why does `svnversion -c` give me a range?
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Dec 4, 2013, at 06:00, Cooke, Mark wrote:
> I would like to include the svn revision number in my project's version info but I am confused by the results of svnversion. I want the version number of a tagged tree to always be the same (i.e. the last commit to the tag) but if the tag is to be rebuilt using a fresh checkout some time later `svnversion` seems to report the HEAD revision. So I looked at `svnversion -c` but this always seems to give me a range e.g. `2:1476`, even directly after an update.
>
> I have read the red book but it is quite vague about the -c option. Why is `-c` always giving me a range?
I think the `-c` option means: given all the item in this directory and recursive subdirectories, give the oldest and newest changed file. So, the oldest item in your working copy was last changed in revision 2, and the newest was last changed in revision 1476.
And `svnversion` without any flag does seem to give the latest revision to which the working copy was updated, not the last changed revision.
If you want the last changed revision, you could use:
svn info | sed -n 's/^Last Changed Rev: //p'
RE: Why does `svnversion -c` give me a range?
Posted by "Cooke, Mark" <ma...@siemens.com>.
Hi Bob,
> -----Original Message-----
> From: Bob Archer [mailto:Bob.Archer@amsi.com]
> Sent: 04 December 2013 15:22
>
> > Hi Folks,
> >
> > I would like to include the svn revision number in my
> > project's version info but I am confused by the results
> > of svnversion. I want the version number of a tagged
> > tree to always be the same (i.e. the last commit to the
> > tag) but if the tag is to be rebuilt using a fresh
> > checkout some time later `svnversion` seems to report
> > the HEAD revision. So I looked at `svnversion -c` but
> > this always seems to give me a range e.g. `2:1476`, even
> > directly after an update.
> >
> > I have read the red book but it is quite vague about the
> > -c option. Why is `-c`
> > always giving me a range?
> >
> > Many thanks,
> >
> > ~ mark c
>
> If you are on windows you can use SubWCRev which is
> distributed with tortoiseSVN. It is designed to do what you want.
>
> http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
>
> BOb
Thanks very much, I do not know how I have managed to not notice that since we have been using TortoiseSVN for years...
Interestingly, the sample keyword file does not seem to work properly:
char *Revision = "$WCREV$"; >> char *Revision = "1755";
char *Revision16 = "$WCREV&0xFF$"; >> char *Revision16 = "$WCREV&0xFF$";
...but that is for another list.
~ mark c
RE: Why does `svnversion -c` give me a range?
Posted by Bob Archer <Bo...@amsi.com>.
> Hi Folks,
>
> I would like to include the svn revision number in my project's version info
> but I am confused by the results of svnversion. I want the version number of
> a tagged tree to always be the same (i.e. the last commit to the tag) but if the
> tag is to be rebuilt using a fresh checkout some time later `svnversion` seems
> to report the HEAD revision. So I looked at `svnversion -c` but this always
> seems to give me a range e.g. `2:1476`, even directly after an update.
>
> I have read the red book but it is quite vague about the -c option. Why is `-c`
> always giving me a range?
>
> Many thanks,
>
> ~ mark c
If you are on windows you can use SubWCRev which is distributed with tortoiseSVN. It is designed to do what you want.
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-subwcrev.html
BOb