cmpilato@collab.net gave the following scenario as an example of use
case B for 'svn cp':
>> Say I have a working copy, up-to-date with the head revision (which is
>> 19). I also have a file, foo.c, which I decide to delete.
>>
>> `svn rm foo.c` # schedule foo.c for deletion
>> `svn ci` # commit the deletion of foo.c, now repos is rev. 20
>>
>> Time (and revision history) goes by, and oh, crud. I just remembered
>> that I actually *needed* that file. No problem, just restore it, and
>> continue history from where it left off.
>>
>> `svn cp -r 19 http://server/repos_path/to/foo.c` foo.c
>>
>> Now, I have a working copy with foo.c back in it, scheduled for
>> addition. When I commit, I have essentially restored foo.c from where
>> it left off.
On Monday, November 19, 2001, at 04:32 AM, Mo DeJong countered with the
idea of accomplishing the same task with a merge subcommand:
> I thought about this some more and I realized why this
> operation was bothering me so much, it mixes merge
> behavior in with the cp command. This seems like yet
> another example of the "super command" fever that
> has swept the list of late.
>
> This restore a deleted file operation would be
> a reverse double -j merge in CVS. Here is a quick
> example:
[ snip example]
> Now, I know we are not supposed to talk about merges until the
> next release is done, but since it seems the copy command would
> be doing merge like things we should address this now. I don't
> have a problem with the functionality, I just care about how
> it is presented to the user.
>
> I claim that merging should have its own subcommand. We should
> not repeat the mistake of cvs by overloading some other
> subcommand.
>
> The subcommand usage might look like:
>
> svn merge [URL] [-r rev] [wc_path]
>
> One might merge changes from a branch named "mybranch" like so:
>
> % svn merge $URL/mybranch
>
> 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. Because Subversion
relies on copies to do branching and tagging, you need a general,
flexible copy primitive in order to be able to take full advantage of
the revision history available in the repository. CVS uses a different
tagging and branching model, so tasks that require a merge in CVS might
not in Subversion simply because that copy primitive is, in fact,
available. That doesn't imply that merge behavior gets mixed in with
copies.
>>> svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
>>> svn co http://foo.com/proj/branch
>>> cd branch
>>> # Make mods and mix revs
>>> svn commit
>>
>> You can't easily make the mods and mix revisions here. I mean, let's
>> put some numbers with your example:
>>
>> Say the head revision is 19.
>>
>>> svn cp http://foo.com/proj/trunk http://foo.com/proj/branch
>>
>> Okay, so now there is a revision 20 with a copy of trunk.
>>
>>> svn co http://foo.com/proj/branch
>>
>> Now I have a working copy at revision 20, just of the branch.
>>
>>> cd branch
>>> # Make mods and mix revs
>>> svn commit
>>
>> Hm...mix revs. From what? Prior to revision 20, there was nothing in
>> this particular portion of the source tree. Plus, now I've had to
>> suffer an extraneous checkout (not an update, mind you) to get this
>> done.
>
>
> 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." But that's revision 150 of
what? Remember that the working copy reflects
http://foo.com/proj/branch. And since http://foo.com/proj/branch/subdir1
was created at r200, it didn't exist at r150. In order to accomplish
this, you'll need to do a copy:
svn cp -r 150 http://foo.com/proj/trunk/subdir1 subdir1
This is use case B.
> 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.
> svn commit -m "created new mixed rev branch"
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.
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