You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Berlin <db...@dberlin.org> on 2005/03/09 17:55:47 UTC
Weird behavior from checkout
If you use svn co -r 2 <path>, the server will open every single
revision, and eventually give you revision 2
if you use svn co -r 2 <path>@2, the server will open revisions 2, and
1, and give you revision 2.
This is because the peg_revision that gets passed down by checkout to
trace_node_locations will be <HEAD> in the first case, and 2, in the
second case.
In both cases, the start revision number will be correct.
I don't understand why the first shouldn't do the exact same thing as
the second on the server.
The attached patch gives me the desired behavior.
All it does is say "when you've specified a start revision, use that as
the peg revision".
After all, it doesn't seem to make sense to say something like:
svn co -r 5 <path>@41081
or
svn co -r 4 <path>@3
I could warn about conflicts between peg and start if we want.
So what i am missing?
Re: Weird behavior from checkout
Posted by Greg Hudson <gh...@MIT.EDU>.
On Wed, 2005-03-09 at 12:55, Daniel Berlin wrote:
> If you use svn co -r 2 <path>, the server will open every single
> revision, and eventually give you revision 2
Only the revisions which affect <path>. If we decide to go with the
svn_fs_closest_copy() solution to issue #1970, this will get
significantly better. (But it would mean that per-revision node ACLs
would never be able to block history traversal, because we would no
longer be looking at all of the revs between the peg rev and the target
revision when looking up locations.)
Maybe the current default peg rev for URLs isn't best (it's a tough UI
issue), but I think the performance issue should be treated as
orthogonal.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Mark Phippard <Ma...@softlanding.com>.
Scott Palmer <sc...@2connected.org> wrote on 03/09/2005 02:01:47
PM:
> That is tricky. I like Daniel's preference. Since if I browse rev X of
> the repository and write down the structure I see there, I expect "svn
> co -rX URL" to work if I give it one of the URLs I wrote down -
> regardless of what might have happened with the specified folder or
> file in other revisions.
>
> But... at the same time, I like the ability to specify URLs in the HEAD
> and get a trace back to a different URL. For working copies when you
> specify a PATH, I think it should take the rev of the PATH in the
> working copy as the starting point, not HEAD.
I believe that is how it works. If PATH is a WC, then the default peg
revision is the revision of that item in the WC. If PATH is a URL then
the default peg revision is HEAD.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Scott Palmer <sc...@2connected.org>.
On Mar 9, 2005, at 1:37 PM, Ben Collins-Sussman wrote:
>
> So what you're seeing here is a widespread consistent behavior across
> all commands:
>
> svn command -rX path
>
> 1. go to path@HEAD
> 2. trace rename history back to rX
> 3. use that (possibly different) location in rX
>
> It just so happens that in the case of 'svn co -rX URL', this new
> syntax and behavior is contradicting an equally valid interpretation
> of what to expect. :-/
>
> Is this tricky to explain to users? It's not yet documented in the
> book, though I plan to fix that.
That is tricky. I like Daniel's preference. Since if I browse rev X of
the repository and write down the structure I see there, I expect "svn
co -rX URL" to work if I give it one of the URLs I wrote down -
regardless of what might have happened with the specified folder or
file in other revisions.
But... at the same time, I like the ability to specify URLs in the HEAD
and get a trace back to a different URL. For working copies when you
specify a PATH, I think it should take the rev of the PATH in the
working copy as the starting point, not HEAD.
Scott
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Norbert Unterberg <ne...@gmx.net>.
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.
Norbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Daniel Berlin <db...@dberlin.org>.
On Wed, 9 Mar 2005, Ben Collins-Sussman wrote:
>
> On Mar 9, 2005, at 12:15 PM, Daniel Berlin wrote:
>>
>> I believe this because that is what i believe most users expect (in fact,
>> i only noticed all of this because 3 different ex-cvs users brought it to
>> my attention)
>> I will simply note that I still find it completely unintuitiveand will
>> spend years trying to get users to use one syntax over the other because
>> it is so much faster and less load on the server :)
>>
>
> The whole peg-revision feature is new, and is the result of svn users
> complaining that commands don't follow renames.
>
> For example, people would run
>
> svn cat -rX foo.c
>
> And get errors about foo.c not existing in rX, when in fact it *did* exist,
> but in a different location. We especially got complaints about 'svn diff'
> not following renames.
>
> So what you're seeing here is a widespread consistent behavior across all
> commands:
>
> svn command -rX path
>
> 1. go to path@HEAD
> 2. trace rename history back to rX
> 3. use that (possibly different) location in rX
>
> It just so happens that in the case of 'svn co -rX URL', this new syntax and
> behavior is contradicting an equally valid interpretation of what to expect.
> :-/
Yes.
i can also see how it's very useful for other commands, and doesn't
really conflict with existing behavior there.
>
> Is this tricky to explain to users?
Yes, but i can do it by using REALLY LARGE LETTERING AND ALL CAPITAL
LETTERS.
CVS people tend not to use peg revisions, so they don't understand that
their is a significant difference in the commands i originally mentioned.
They tend to think of files as revisioned, instead of trees, until they've
used subversion for a while.
> It's not yet documented in the book,
> though I plan to fix that.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Ben Collins-Sussman <su...@collab.net>.
On Mar 9, 2005, at 12:15 PM, Daniel Berlin wrote:
>
> I believe this because that is what i believe most users expect (in
> fact, i only noticed all of this because 3 different ex-cvs users
> brought it to my attention)
> I will simply note that I still find it completely unintuitiveand will
> spend years trying to get users to use one syntax over the other
> because it is so much faster and less load on the server :)
>
The whole peg-revision feature is new, and is the result of svn users
complaining that commands don't follow renames.
For example, people would run
svn cat -rX foo.c
And get errors about foo.c not existing in rX, when in fact it *did*
exist, but in a different location. We especially got complaints about
'svn diff' not following renames.
So what you're seeing here is a widespread consistent behavior across
all commands:
svn command -rX path
1. go to path@HEAD
2. trace rename history back to rX
3. use that (possibly different) location in rX
It just so happens that in the case of 'svn co -rX URL', this new
syntax and behavior is contradicting an equally valid interpretation of
what to expect. :-/
Is this tricky to explain to users? It's not yet documented in the
book, though I plan to fix that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Daniel Berlin <db...@dberlin.org>.
On Wed, 2005-03-09 at 13:05 -0500, Mark Phippard wrote:
> Daniel Berlin <db...@dberlin.org> wrote on 03/09/2005 12:55:47 PM:
>
> > If you use svn co -r 2 <path>, the server will open every single
> > revision, and eventually give you revision 2
> >
> > if you use svn co -r 2 <path>@2, the server will open revisions 2, and
> > 1, and give you revision 2.
> >
> > This is because the peg_revision that gets passed down by checkout to
> > trace_node_locations will be <HEAD> in the first case, and 2, in the
> > second case.
> >
> > svn co -r 5 <path>@41081
> >
> > or
> > svn co -r 4 <path>@3
> >
> >
> > I could warn about conflicts between peg and start if we want.
> >
> > So what i am missing?
>
> Say you have a folder named "foo" that is moved to "bar" in r3. If you
> then run the following commands:
>
> svn co -r 2 url://bar
>
> will succeed and checkout foo.
Uh, that's a little weird.
Especially since you asked for *revision 2* of that url, and it doesn't
exist in revision 2.
>
> svn co -r 2 url://foo
>
> will fail, because there is no foo at HEAD.
This is also weird, since foo existed in *revision 2*
>
> That is what the peg revisions are for. The default of HEAD means that
> you want revision 2 of what is currently named "bar".
>
I understand why you think the above is correct (The URL specifies a path in the HEAD revision which you are asking about an older revision for)
However, i believe the revision number you specify in checkout should be implied to be the revision of the url you are asking for, unless you specifically ask for a different URL/peg revision.
IE the above commands you want would be written svn co -r 2 url://foo@HEAD
I believe this because that is what i believe most users expect (in fact, i only noticed all of this because 3 different ex-cvs users brought it to my attention)
I will simply note that I still find it completely unintuitiveand will spend years trying to get users to use one syntax over the other because it is so much faster and less load on the server :)
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Weird behavior from checkout
Posted by Mark Phippard <Ma...@softlanding.com>.
Daniel Berlin <db...@dberlin.org> wrote on 03/09/2005 12:55:47 PM:
> If you use svn co -r 2 <path>, the server will open every single
> revision, and eventually give you revision 2
>
> if you use svn co -r 2 <path>@2, the server will open revisions 2, and
> 1, and give you revision 2.
>
> This is because the peg_revision that gets passed down by checkout to
> trace_node_locations will be <HEAD> in the first case, and 2, in the
> second case.
>
> svn co -r 5 <path>@41081
>
> or
> svn co -r 4 <path>@3
>
>
> I could warn about conflicts between peg and start if we want.
>
> So what i am missing?
Say you have a folder named "foo" that is moved to "bar" in r3. If you
then run the following commands:
svn co -r 2 url://bar
will succeed and checkout foo.
svn co -r 2 url://foo
will fail, because there is no foo at HEAD.
That is what the peg revisions are for. The default of HEAD means that
you want revision 2 of what is currently named "bar".
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org