Ben,
Thank you for such a fast response. Obviously, I have more reading and
learning to do. In the mean time, we love Subversion!
One thing, though, is a little counter-intuitive for me...
First, let me say that I understand (now) the need for @PEGREV for cases
where objects are renamed and moved around, yet still present in some form
in HEAD. Considering and example "svn co -rX URL@Y" (where X and Y are
different) makes sense, especially when the object had one (perhaps widely
known) name in revision Y and a different (perhaps obscure) name in
revision X -- so Subversion traces back from Y, through the rename, to X.
Then it makes sense for "svn co -rX URL" to be same as "svn co -rX
URL@HEAD". OK, so far so good.
But... It seems to me that Subversion could be just a little smarter for
cases where the object cannot be found in HEAD. Instead of raising an
error condition, could Subversion go one step further and try looking only
at version X (given "svn co -rX URL")? This is a case where there is no
ambiguity and so no additional information is necessary. Obviously, there
is a cost/benefit consideration, but I suspect many users migrating from
CVS would run into this (since "-rX" was all-mighty in CVS).
My immediate problems are solved by getting used to the @PEGREV syntax, so
I am not insisting on any changes to Subversion. These are just thoughts
from an un-enlightened user.
I value your opinions on the subject!
--Mike
On Monday 12 September 2005 21:00, Ben Collins-Sussman wrote:
> It's not a workaround, peg revisions are the proper syntax.
> If you type
> svn checkout -rX URL
> That's equivalent to typing
> svn checkout -rX URL@HEAD
> But if URL@HEAD doesn't exist, you get the error you're seeing.
> What you want to type is
> svn checkout URL@X
> Read about peg revisions in the book:
> http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
> On Sep 12, 2005, at 7:03 PM, Mike Linda wrote:
> > When I use @PEGREV at the end of the path, it also checks out the
> > older version subset -- although I read somewhere that this was a
> > workaround.
--
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 13 18:26:05 2005