Greg Hudson <ghudson@MIT.EDU> writes:
> >> My question is, what happens in the working directory when I run
> >> the "svn branch" command?
>
> > I think it should switch over too, unless you explicitly request
> > that it not.
>
> So, in Jim's conception of the world, a branch is exactly like a copy,
> and is visible in the filesystem like a copy would be.
>
> That world view suggests that the wc has to make a copy of the whole
> directory. (With some conceivably funky admin files.) Which is
> decidedly not a fast operation--slower than a CVS tag operation, even.
>
> So I remain confused as to whether (a) I don't know something about
> the wc view of branches, and how it meshes with the filesystem view of
> branches, or (b) nobody has really thought about this yet.
Suppose you've got a working directory whose root is WD (that is,
WD/.. is an ordinary directory, not under version control). WD
corresponds to some directory in the repository, http://HOST/REPO/RD.
If RD is the repository root, then you're right --- any copying within
the repository must mean copying in the WD. So we may be able to copy
huge trees instantly in the repository, but the same is not true in
WD, so it's kind of pointless.
So suppose RD isn't the root; suppose it's
http://HOST/REPO/main/project. To make a branch, we do as follows:
svn cp http://HOST/REPO/main/project http://HOST/REPO/branch/project
and then do this, with WD as our current directory:
svn update -r http://HOST/REPO/branch/project
In other words, "apply the changes necessary to turn my current WD
into http://HOST/REPO/branch/project". Think like "cvs update -r".
Subversion will compute the delta between WD's current contents
(/main/project) and its desired contents (/branch/project), recognize
that they're identical, make no changes, but update all the base paths
in the working copy to refer to things in
http://HOST/REPO/branch/project.
Now your working directory is on a branch.
In summary, to branch, you don't copy things within your working
directory and commit that. That'd be slow and clumsy. Instead, you
do a copy directly in the repository of some parent of your working
copy's base directory to some other place outside your working copy's
base directory. Then you can simply adjust your working copy's base
paths accordingly to refer to the copy you just made; since you know
it's an exact copy, none of your files need to be touched.
So all the metadata in your tree is affected, but I think
that's mostly inevitable.
Note that I don't mean to actually advocate `svn update -r' as the
right syntax. I have no grand insights as to what the right user
interface for this might be. `svn branch' could do both the copy and
the "update", or whatever you want to call it.
Received on Sat Oct 21 14:36:23 2006