[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Q: usage model for creating a branch

From: <andy.glew_at_amd.com>
Date: 2004-04-22 16:11:38 CEST

Q: what is the usual SVN usage model for creating a branch?

(Please let me head off stupid responses such as "Just make
a copy".)

I started out using the official way
that seems to be recommended by the Subversion book
bt it seems to require absolute URLs.

I've come up with my own mechanism that doesn't
require so many clunky absolute URLs.
However, it is not so elegant as creating a branch was
in CVS.

---+ The Official Way

E.g. my workspace is a leaf somewhat deep in the directory tree:

http://svnRepo/project/trunk/path1/path2/path3/path4/myModule

Based on my reading of the Subversion book, I started out creating
branches using

   svn cp myModule http://svnRepo/project/branches/path1/path2/path3/path4/myModule
or maybe
   svn cp myModule http://svnRepo/project/branches/myModule

depending on whether the module I am branching needs to have
all of its dependencies on higher elements in the tree, or not.

Another way, switching in place:
   svn switch http://svnRepo/project/branches/myModule

But again, absolute URLs. Much less elegant than the CVS way.

---+ My current Subversion way to create branches

Imagine that I am in a working directory
/workspace/glew-parihar-work/path3/path4/myModule
checked out from
http://svnRepo/project/trunk/path1/path2/path3/path4/myModule

I.e. I have a subproject, not the full project, checked out.

To create a branch for myModule, I do
cd /workspace/glew-parihar-work/path3/path4
(i.e. I change to the parent of myModule
- which I usually do with a relative path, cd ..,
or the like.)

Then I create the branch *IN* the directory tree.
I.e.
   
    cd ..
    svn cp myModule myModule-branch-YYMMDD

(Unfortunately,
    svn cp . ../myModule-branch-YYMMDD
does not work, at least on the 1.0.1 version I am using.)

PRO: no absolute path

CON: I now have two directories
/workspace/glew-parihar-work/path3/path4/{myModule,myModule-branch-YYMMDD}

If my build tools (e.g. Makefiles) have dependencies from
higher to lower in the tree - i.e. from path3 to pathh3/path3/myModule,
these tools will break in the new environment.
(However, stuff I create almost never has this problem:
I make my modules and directory trees as independent as possible,
to facilitate testing, independent work, etc.
Still, occasionally it arises, often with others' code.)

CON: because I have two directories, it is imperative
to kill the branch as soon as possible.
Keeping the branch around for a long time is bad
- the branch appears to others when they check out "trunk".
(And the only way in Subversion to avoid that seems to be
to use clumsy aboslute URLs.)

CON: This usage pattern does not support "propagating the branch"
iteratively up the tree, as far as is needed - something that
is easy to do with CVS. I'll explain this below.

---+ My CVS Way

My first rule about branching in CVS: never use rtag.

Rather, within a workspace - typically, when you have
been doing some edits on the trunk and have just realized
that you want to check them in, although broken,
and hence need a branch:

In workspace /workspace/glew-parihar-work/path2/path3/path4/myModule
checked out from CVS repo
/cvsRepo/project/trunk/path1/path2/path3/path4/myModule

I type
   cvs-make-branch BranchName-YYMMDD .
which is actually
   cvs tag -b BranchName-YYMMDD .
   cvs update -r BranchName-YYMMDD .

Note that this creates a branch
   (1) without using long absolute pathnames
   (2) without creating any new directories
       in what gets checked out by anyone,
       on either branch or trunk
(We'll skip over the part where the CVS branch
is visible to cvs log from both trunk and branch;
as opposed to svn, which makes it pretty hard to
see what is happening on the branch when you
have a trunk workspace.)

If I realise that I need to "propagate the branch"
- if I realize that I don't need just myModule in
the branch, but I also need path4, I do

   From /workspace/glew-parihar-work/path2/path3/path4/myModule
   Where I originally did
      cvs-make-branch BranchName-YYMMDD .
   I propagte the branch up the directory tree to path4 by doing
      cd ..
      cvs-make-branch BranchName-YYMMDD .
   and then, maybe all the way up to path2 (including path3)
      cd ../..
      cvs-make-branch BranchName-YYMMDD .

The cvs-make-branch (cvs tag -b/update -r)
automatically apply to the already branched files.
In some sense, you can say that it automatically merges
- I usually apply tags if I have already checked things
in.

In Subversion, "propagating the branch upward" means copying
stuff that was in the old branch to a new branch.
E.g.
   Starting in workspace
      /workspace/glew-parihar-work/path2/path3/path4/myModule
   Create the branch for myModule
      cd ..
      svn cp myModule myModule-branch-YYMMDD
      svn ci
   After working for a while, realize that I need to
   propagate the branch to path4
      cd .. (into path3)
      svn cp path4 path4-branch-YYMMDD; svn ci
      svn rm path4-branch-YYMMDD/myModule; svn ci
      svn mv path4-branch-YYMMDD/myModule-branch-YYMMDD

I.e. the branch identity changes - I have not really
"propagated the branch", but have created a new branch
into which the old branch is moved.

This subversion way of "propagating the branch"
has pros and cons:
   PRO: it automatically records the fact that the branch
        was propagated
   CON: there are really two branches

---+ Conclusion

I ask questions about usage models for branching on Subversion.

I think that the "official" way requires absolute URLs,
which I do not like.

I have come up with my own way that avoids absolute URLs,
but it does not cleanly separate branch and trunk.

I compare this to CVS, where branch and trunk are cleanly separated,
and where "propagating the branch" is easy.

I am very interested in any advice as to how to do this better.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Apr 22 16:12:33 2004

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.