2007/5/10, Ben Collins-Sussman <sussman@red-bean.com>:
> Subversion hasn't yet ever used 'changeset' as part of its official
> vocabulary. If you look at the description of the '-c' option, it's
> just called 'change', and is short for -rN-1:N. If we want to stay
> in the current Subversion universe, we would use the term 'revision'
> to refer to both a tree and a changeset, depending on context. :-)
I recently ran into some problems because "-cN" should not be the same
as "-rN-1:N" in some real-world scenarios. It is the same if you look
at the complete repository, but can make a difference when you deal
with branches.
Example:
create repo structure with trunk and branches folder, and a file in trunk --> r1
checkout trunk into two different WC: wc1 and wc2
change file in wc1 and commit --> r2
change file in wc2 and create branch from wc2 --> r3
switch wc2 to the new branch
A "svn diff -c3 wc2" fails with
"svn: Unable to find repository location for 'wc2' in revision 2"
I think this is because -c3 expands to -r2:3. r2 is not the ancestor
of wc2@3, but r1 is. A svn diff -r1:3 wc2 succeeds.
Shouldn't Subversion use some kind of history tracking when called
with -cN? At least people should stop telling users that -rN-1:N gives
the change that lead to rN, because it does so only in most cases, but
not in the general case.
Well, this has nothing to do with merge tracking, but I could not
resist. Or wait, how would merge tracking hande this case when you
merge branch back to trunk?
Complete reproduction script (for windows, svn 1.4.3, renamed due to
Gmail limtations) attached.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat May 12 15:43:52 2007