RE: Why does `svnversion -c` give me a range?
Hi Bob, -Original Message- From: Bob Archer [mailto:bob.arc...@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= $WCREV0xFF$;char *Revision16= $WCREV0xFF$; ...but that is for another list. ~ mark c
RE: Why does `svnversion -c` give me a range?
-Original Message-
From: Daniel Shahaf [mailto:d...@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\Codesvn --version
svn, version 1.7.10 (r1485443)
compiled Jun 1 2013, 07:40:50
snip
D:\PROJECTS\Support\Codesvn up .
Updating '.':
At revision 638.
D:\PROJECTS\Support\Codesvnversion .
638
D:\PROJECTS\Support\Codesvnversion . -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?
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\Codesvn --version
svn, version 1.7.10 (r1485443)
compiled Jun 1 2013, 07:40:50
snip
D:\PROJECTS\Support\Codesvn up .
Updating '.':
At revision 638.
D:\PROJECTS\Support\Codesvnversion .
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\Codesvnversion . -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?
-Original Message-
From: Ryan Schmidt [mailto:subversion-20...@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\Codesvn --version
svn, version 1.7.10 (r1485443)
compiled Jun 1 2013, 07:40:50
snip
D:\PROJECTS\Support\Codesvn up .
Updating '.':
At revision 638.
D:\PROJECTS\Support\Codesvnversion .
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\Codesvnversion . -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?
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?
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
Re: Why does `svnversion -c` give me a range?
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-20...@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:\PROJECTsvn update Updating '.': At revision 1770. D:\PROJECTsvnversion . 1770M D:\PROJECTsvnversion . -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?
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?
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
