...
> > The restore a deleted file operation could be accomplished like so:
> >
> > % svn rm one
> > % svn commit one
> >
> > (assume the commit created rev 2)
> >
> > % svn merge -r 2:1 one
> > % svn commit one
> >
> > Doesn't that seem a whole lot cleaner that use case B?
>
> I agree that some type of merge command will probably be necessary, but
> I think this is a different operation than a copy.
...
>That doesn't imply that merge behavior gets mixed in with copies.
Well, I think we are agreed that copy and merge are different things.
What I am saying is that case B as outlined is really just a merge to
an earlier revision (before the file got deleted). I am not talking about
how it is implemented, rather how it is presented to the user.
...
> > It seems like this is yet another place where a merge command could
> > be very useful. Assume we had a merge command and used it along with
> > the switch subcommand to create a new branch and then mix in some older
> > revs in the new branch. The following could be done instead of use
> > case C.
> >
> > svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
> > svn switch http://foo.com/proj/branch
>
> This is a perfect example of what cmpilato (I think...) was talking
> about. Let's assume that the copy in the example above creates revision
> 200.
>
> > svn merge -r 150 subdir1
>
> Translating this command to English we get something like "merge the
> changes that occurred between revision 1 and revision 150 in the
> directory subdir1 into the working copy."
Sorry, I meant "undo the changes made in subdir1/ between revs 150 and 200".
That would let us create a branch that had older revisions of specific subdirectories
or files in it. Perhaps it would be more clear as "snv merge CURRENT:150 subdir1",
but I am not sure if there is a symbolic rev id that applies to the current revision.
...
> > svn merge -r 178:170 subdir2
>
> In this case, you will need a merge subcommand (since copying from
> revisions 170 through 178 doesn't make sense), but "-r 178:170" will be
> insufficient to specify what changes to merge into the working copy.
> You'll need a URL so that svn can find the files:
>
> svn merge -r 178:170 http://foo.com/proj/trunk/subdir2 subdir2
>
> I guess in the case where http://foo.com/proj/branch *did* exist between
> r170 and r178 the URL could be omitted.
I don't get that at all. The revision numbers apply to the whole tree right?
A plain revision number should be enough info to merge backwards from
a URL that was created with a copy command. I would agree that when
you wanted to merge forward you would need to supply a URL and a
revision to merge to.
Here is a quick example:
(assume we checked out .../HEAD)
svn cp project branch
svn commit -m "created branch" branch
cd branch
(create foo.c and bar.c)
svn add foo.c bar.c
svn commit foo.c bar.c -m "added foo.c and bar.c on branch"
Assume the initial rev was 9, before we added the branch dir.
We added the branch subdir and that created rev 10.
We then added foo.c and bar.c and that created rev 11.
Then we go off and do a bunch of other commits and
end up at revision 50 for the whole tree.
What I am saying is that I should be able to go into a
subdir and "undo" some changes to a specific file
or directory. Like so:
cd branch
svn merge -r 50:9 bar.c
That should schedule bar.c for removal, just the opposite
of the commands that added bar.c during the transition
from state 10 -> 11. The .svn/entries file will have
an ancestor=$URL entry, so the system should know
I am talking about $URL/bar.c here. I don't see why
I would need to give the fully qualified URL here (ala case B).
> So basically I'm saying that you do need a copy command with all
> permutations of wc paths and URLs in its operands. The fact that CVS
> requires you to do a merge to accomplish the same task doesn't imply
> that svn's copy command does a merge.
That sure seems like a merge to me. I am not saying there is no use for
case B, just that the example of recovering a deleted file by reverting
to an earlier revision does not seem like a "copy" operation.
Mo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 2006