On Tuesday, November 20, 2001, at 03:25 PM, Mo DeJong wrote:
>>
>>> 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.
I don't think that would work for you either. Remember that
/proj/branch/subdir1 was created at revision 200. So reversing that
change would mean deleting subdir1 from the working copy.
>>> 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.
Again, /proj/branch/subdir2 didn't exist between r170 and r178, so
reversing those transactions wouldn't do anything.
What you wanted, I think, was to get the changes to /proj/trunk/subdir2
between170 and 178, and apply them in reverse to the working copy. But
since the working copy's ancestor is http://foo.com/proj/branch, you
need to supply the URL to make that happen. Remember /proj/branch really
is a copy of /proj/trunk, not a symlink or something.
> 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
Ok, sure. I suspect that the merge command will let you do just that,
when it gets implemented. On the other hand, if you wanted to get rid of
bar.c, you could just do this:
svn rm bar.c
Surely that's simpler than digging through the commit logs to see where
bar.c was added and then reversing that commit?
> 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).
Yup, in this scenario, you wouldn't need the URL.
>> 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.
It depends on how you look at it. The situation is that you need to
create a certain file with certain data in it. You know that the file
existed in the past. One way to get it back is to "undo" the deletion of
the file. Another way is to copy it out of the past into the present.
Either way, you get the file back.
Strictly speaking, you only need use case A of the copy command. In all
cases, you can check out the entire repository, do a copy-with-history
in your working copy and commit. But that can be a fairly expensive
operation, in terms of bandwidth, local disk space, time, and user
keystrokes. So allowing copies to and from URLs is a big win.
At the same time, I contend that 'svn cp' is a much better user
interface than 'svn merge'. Copying is a very well defined operation and
easy to understand. Imagine doing development without the benefit of
software that handles versioning automatically. You'd do it all with
copies - making "backups" of the source tree at various stages of
development that you might want to go back and look at. Subversion just
makes the storage of all those copies efficient and provides some tools
for examining the relationships between copies.
A merge is a more complicated operation. It is necessary for some of the
strange things we sometimes need to do with version control, but it's
fundamentally less intuitive than a copy. CVS uses merges for
everything, but that's because CVS can't do copies. I think the merge
command in Subversion should be narrower in scope, and used only when a
merge is truly necessary, like reintegrating branches into the main line
of development.
Cheers,
Colin
---------------------------------------------------------------------
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