Frodak Baksik wrote:
> Actually it won't because as according to the documentation the copy
> command does not use peg revisions. Here, I'll quote it for you:
>
> From the book:
> A second, more targeted strategy is not to use svn merge at all, but
> rather the svn copy command.
> Simply copy the exact revision and path "coordinate pair" from the
> repository to your
> working copy:
> $ svn copy --revision 807 \
> http://svn.example.com/repos/calc/trunk/real.c ./real.c
> $ svn status
> A + real.c
Oh my, that is really messed up. The copy command then, uses the common
parameter in a manner that is inconsistent with the way that common
parameter is used with all other svn commands. The other commands
resolve the name in the peg revision, then track the history back to the
revision specified in -r. Copy interprets -r AS the peg revision. This
inconsistency is poor behavior.
> This suggests to me if that you can't locate the item via e.g. ls
> file@rev then it just doesn't exist in that revision. The behavior
> you are implying is buggy seems to be an extension of this metaphor.
>
> I'll just end it with I don't agree with your interpretation of object
> existence in regards to subversion even though your interpretation may
> have been appropriate for other CM tools that I've used.
If you accept that it is ok philosophically to have a hole in a timeline
where a thing did exist, then doesn't, then does again, without having
undergone creation or destruction in between, that is your choice I
suppose, but it does break assumptions made by other parts of subversion
( the -rPREV I mentioned ) so it appears to not be intentional.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 20 17:07:45 2007