On 13 Nov 2001 19:45:22 -0600
cmpilato@collab.net wrote:
> > > B. svn cp URL [-r rev] wc_path
> > >
> > > This "checks out" URL (in REV) into the working copy at
> > > wc_path, integrates it, and schedules it for addition with
> > > history.
> >
> > Humm, I have to admit I don't get it. Could you describe how case
> > B would actually be used? Is this how users are expected to merge
> > changes from another branch into the WC?
>
> 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.
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:
% echo 1 > one
% cvs add one
% cvs commit -m "" one
% rm one
% cvs rm one
% cvs commit -m "" one
Now to get the file back from its dead state. Assume
that the above checking created revisions 1.1 and 1.2.
% cvs update -j 1.2 -j 1.1 one
U one
% cvs up
A one
% cvs diff one
Index: one
===================================================================
RCS file: one
diff -N one
--- /dev/null Tue May 5 13:32:27 1998
+++ one Mon Nov 19 03:42:58 2001
@@ -0,0 +1 @@
+1
% cvs commit -m "restored file one" one
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?
> > 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
svn merge -r 150 subdir1
svn merge -r 178:170 subdir2
svn commit -m "created new mixed rev branch"
The above would not require an extra checkout and it could
provide the same functionality. The real benefit of this is
that the cp command would not have a "special case" where it
would also do a commit behind the scenes. The cp command
would only need to support use cases A and D.
cheers
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