Mo DeJong <supermo@bayarea.net> writes:
> Uhh, you are scaring me a little. All powerfull commands are not
> necessarily a good thing.
Don't sweat it. If you want to write a wrapper script to hide the
power, you're welcome to do so. :-)
> > 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.
> 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.
> > Second, we have a new command: 'svn switch URL [-r rev]'
>
> Here is a wacky idea. How about we just avoid including this functionality?
> Sure, it is possible to write code to do this, but perhaps we don't need to.
> Why can't the user just go to a new directory and checkout a branch?
> I really wonder if actual users are going to use this command much? There
> is a non-zero cost associated with adding a new svn subcommand. We have
> to document it and each user would have to learn what it does. My point is
> that we should really have a good justification for each subcommand and
> I am not sure this "change the URL of my WC update" is really that useful.
Users will likely do this pretty regularly. Say I want to branch the
tree so I work on some experimental code. I do my copy of .../trunk
to .../branches/cmpilato-branch. Now, you're asking me to do a costly
checkout (again, no diffs here, baby) just so I can download
essentially *exactly* what I already have on disk!! Seriously, in
this case, we'd like to be able to say, "Gee, the branch you're trying
to convert your working copy to is exactly like the working copy you
already have, except the stored URLs are different. Okay, we'll just
update your URLs."
Dude, you seriously need to come hang out with me on my 28.8 home
network connection! :-)
---------------------------------------------------------------------
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:48 2006