[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Weird behavior from checkout

From: Norbert Unterberg <nepo_at_gmx.net>
Date: 2005-03-10 00:23:24 CET

Ben Collins-Sussman schrieb:

> svn command -rX path
> 1. go to path@HEAD
> 2. trace rename history back to rX
> 3. use that (possibly different) location in rX

I find this very intuitive, and it could lead to some trouble when
updating to svn 1.2. I would only expect the diff command to follow
renames (only between the two given revisions), not all the other
commands. Commands that only address a single revision (like ls,
checkout, copy ..) should not follow renames from head to the given.
This rename tracking should be the exception for commands that need it
(maybe diff, merge), not the rule.

It might be too late for these discussions (I have not followed the dev
list), but look at situations like this that might make this feature
annoying (at least for checkout commands)

Imagine you develop both in trunk and branch1, say between revisions 6
and 10. To get trunk at revision 6, you just do
        svn co -r6 svn://repos/trunk trunk_at_r6
Then you decide you make branch1 the new trunk (because it reflects the
new main development line). You rename trunk to oldtrunk in r11, and
rename branch1 to trunk in revision 12.
When you now issue the same command as above:
        svn co -r6 svn://repos/trunk trunk_at_r6
you get the contents of branch1 at revision 6. Probably not what you
expected. I can even imagine a co-worker panicing becase he tries to get
r6 of trunk while the repos it at 11:
        svn co -r6 svn://repos/trunk trunk_at_r6
        error: svn://repos/trunk does not exist in that revision
        (or whatever the error might say exactly)

The same command with gives you two completely different results,
depending if you issue it before or after the rename. It might make
existing scripts incompatible in version 1.2, because in 1.1 a checkout
-rX from trunk always gets what trunk contained in revision X.

It gets even more interesting when moving folders around under trunk:

svn co -r6 svn://repos/trunk
gives you trunk and trunk/folder1

svn co -r6 svn://repos/trunk/folder1
might give you the contents of trunk/folder2 when folder2 has been
renamed to folder1 between r6 and head.

How do you explain this to the user?

Did I miss something? If I misunderstood this thread or the new
behaviour then please ignore this message.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 10 00:26:26 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.