On 2/19/07, Phillip Susi wrote:
> Frodak Baksik wrote:
> > Thinking about this more, you almost never want the behavior you describe.
> >
> > For instance, lets say you have file foo in r10, delete it in r11, and
> > then:
> > svn cp -r10 file:///repo/trunk/foo file:///repo/trunk to restore it in r14.
>
> This command will fail actually; you have to use a peg revision since
> the name /repo/trunk/foo does not exist in HEAD.
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
Also from the client:
copy (cp): Duplicate something in working copy or repository,
remembering history.
usage: copy SRC DST
Please notice that it does NOT include [@PEG] in the description.
> > When you perform the ls, cp, diff, etc commands, for versions 11, 12,
> > 13 you want it to say it does not exist in those versions.
>
> No, you don't. The file did exist in those revisions, it simply had no
> name in any directory in that revision. Once you resolve the name ( in
> HEAD or any other specified peg revision ), you are supposed to be able
> to retrieve the state of that file in any rev as far back as the log
> shows the file was created in.
I'm not going to bother to respond to the rest of your email, because
we have 2 fundamentally different views on what it means for an object
to exist.
This is from the subversion book.
Here's a useful metaphor:
you can think of every object in the repository as existing in a sort
of two-dimensional coordinate
system. The first coordinate is a particular revision tree, and the
second coordinate is
a path within that tree. So every version of your file or directory
can be defined by a specific
coordinate pair.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Feb 20 16:39:22 2007