On Wed, 2005-03-09 at 13:05 -0500, Mark Phippard wrote:
> Daniel Berlin <dberlin@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
Received on Wed Mar 9 19:17:56 2005