On 13 Nov 2001 16:31:22 -0600
Ben Collins-Sussman <sussman@collab.net> wrote:
> Last Friday, gstein flew to Chicago and {gstein, kfogel, cmpilato,
> sussman, fitz} had a grand-old design and brainstorm session about how
> to design the UI for branches, tags, merges, and so on. This mail
> gives an overview of what we'd like to do for svn 0.7.
>
> First, we want to make 'svn cp' into an all-powerful command:
Uhh, you are scaring me a little. All powerfull commands are not
necessarily a good thing.
> 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?
> C. svn cp wc_path URL
>
> This immediately commits wc_path to URL on the server; the
> commit will be an addition with history. The commit will not
> change the working copy at all.
...
> In a more complex case, suppose the state of my tree (mixed revisions
> and all) is exactly what I want the tag to look like. In that case, I
> use case (C):
>
> cd top/of/my/wc
> svn cp . http://foo.com/repos/project1/tags/milestone-6
I don't like this at all. Why should there be any way to commit things
to the repo without using the commit command? Can't we get the
same functionality using D, cp first and then commit the changes?
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
> Second, we have a new command: 'svn switch URL [-r rev]'
>
> This command performs an update on your working copy, making it
> reflect a new URL. This is how you "move" your working copy to a
> branch or tag.
>
> Really, 'svn up' is just a special case of 'svn switch', where the URL
> is assumed to be the one you already have.
>
> There's nothing magical about this command -- it will be fairly easy
> to write, we hope; instead of calling svn_repos_dir_delta() on two
> identical paths, the paths will be different now. The good news is
> that _dir_delta doesn't care one bit. It examines node-rev-ids
> anyway, and notices relationships between them. If, when updating
> your working copy from a trunk to a branch, it discovers that 80% of
> your files are already correct, then it won't send them. (However, if
> you ask to switch your working copy to a completely unrelated URL,
> then dir_delta probably *will* do something as extreme as removing and
> re-checking out a new working copy.)
>
> Also -- if the user has local mods that conflict with the switch, one
> may very well get an 'obstructed update' error. An update is an
> update, after all. Let the user beware; if she wants to switch her WC
> to a branch cleanly, she should make sure her WC is clean to begin
> with. :-)
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.
cheers
Mo DeJong
---------------------------------------------------------------------
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