views:

50

answers:

4

Hi,

When creating a branch, what are the implications of selecting the following?

Create copy in the repository from:

  • HEAD revision in the repository
  • Specific revision the repository
  • Working copy
+4  A: 

In short:

  • creating from the HEAD revision is creating a branch starting from "now", where "now" is the latest version committed to the repository
  • creating from a specific revision is creating a branch starting from a point in the past (identified by its revision number)
  • creating from the working copy is sort of like creating a branch starting from a point in the future (your working copy, as yet uncommitted)

Depending on the purpose for creating the branch, you will usually choose one of the first two options. The third option is probably less commonly used.

You would branch from the HEAD if you want to do some exploratory development for a particular purpose, or you want to start creating a different version for a specific customer or something. You would branch from the past if you need to make a patch to a previously released version of your software.

Greg Hewgill
Thanks for the detailled description, Greg ;)
aspdotnetuser
+1  A: 

HEAD revision in the repository SVN takes the Revision with the highest number so the one which was uploaded last.

Specific revision the repository You can select the revision you would like to get.

Working copy The revision like it is right now in your local workspace (not comitted).

In what situation would you use working copy? Since it's best to get the latest code?
aspdotnetuser
You could use this option to share something in your workspace (For exaple for a colleague to have a second look at it or continiue working on it) which wasn't fully tested so that it shouldn't be uploaded to the real svn branch. To get the latest code which was sucessfully tested I would upload it into the repository and create the branch from the head revision so you have all the changes 100%.
+1  A: 

HEAD will cause the branch to be a copy of the latest committed version of the repository.

Specific revision will cause the branch to be a copy at a specific point in time of the repository.

Working copy creates a branch based on your working copy's latest revision and then commits to this all of your "in progress" changes as well.

EDIT: An example for choosing Working Copy.

You update your working copy with the latest version of the trunk to start making some minor changes.

You realise after a few hours that the job was bigger than you expected and you should've created a branch.

Creating a branch from Working Copy at this point then effectively creates the branch as if you had done it at the beginning.

Robin Day
Thanks Robin. Am I right in thinking, that when you have made changes and commited them to the branch you created, to add those changes to the trunk you need to delete the files, then check in the files from the trunk and then use something like beyond compare to add the files to the trunk files you just checked in?
aspdotnetuser
No, not at all. You can merge your changes back into the trunk. In general you merge any changes made to the trunk back into your branch so it is up to date. Then you reintegrate your branch back into the trunk. The entire branch/merge concept is a whole different question though and can't be answered fully in a comment.
Robin Day
I called option 3 "possibly dangerous" in my writeup, but in this case I think it's fine. As long as there aren't any svn:mergeinfo attributes you might be missing out on when you do that local copy you're probably fine. Since this is an example of copying brand new work to a new branch, I don't see the documentation's caveat applying here.
jasonmp85
+1  A: 

"Creating a branch" in svn is really just making a copy of some subset of your repository. In fact, the SVN Book chapter on branching says as much.

If your directory structure looks like this…

  • project
    • trunk
    • branches
    • tags

and your URL to trunk is: http://example.com/repos/project/trunk, you would:

  1. make a new branch named beta from HEAD like so:

    svn copy http://example.com/repos/project/trunk http://example.com/repos/project/branches/beta
    

    This will immediately create the new branch in the repository and doesn't do anything to your local copy.

  2. make a new branch named ancient from an older revision n like so:

    svn copy -r n http://example.com/repos/project/trunk http://example.com/repos/project/branches/ancient
    

    This is exactly the same as 1, but uses the specific revision.

  3. make a branch named alpha from your local copy, assuming your current directory is trunk:

    cd ../
    svn cp trunk branches/alpha
    

    This will make the copy you requested, but does it locally. According to the SVN book, this is discouraged because it takes a lot longer than making the copy on the repository server (where the copy operation is essentially free).

    There's also this caveat listed when you type svn help copy:

    WARNING: For compatibility with previous versions of Subversion, copies performed using two working copy paths (WC -> WC) will not contact the repository. As such, they may not, by default, be able to propagate merge tracking information from the source of the copy to the destination.

In my experience, way 1 is typically used. 2 is used in some rare cases involving complicated patches to earlier branches, and 3 is never useful (and according to the documentation, slow and possibly dangerous). So stick with 1 unless you have a compelling reason to use one of the other two.

jasonmp85