20 Jan 2011, 17:58
Generic-user-small

Neil Hainer (1 post)

Hi Mike,

Thanks for writing this book, I have found it helpful. The “Pragmatic Guide to Subversion” shows one how to setup a repository, create projects, create branches and how to create tags, etc.

What I am looking for is information on the following topics:

  1. Another developer and myself are going to start out with the same code baseline. I am going to parallelize the existing code. He is going to be adding new functionality. Should we be working in separate projects or in the same project with one of us using the trunk and the other using a branch. If I want to merge my parallel code with his new features at some point down the road, will it be easier to accomplish this using the “trunk and branch” method versus the two separate projects approach?

TIA,

Neil

P.S. Are these type of questions already documented? For instance in your other Subversion book or on the web?

08 May 2011, 01:11
Generic-user-small

Ryan J Ollos (4 posts)

If I want to merge my parallel code with his new features at some point down the road, will it be easier to accomplish this using the “trunk and branch” method versus the two separate projects approach?

If you want to take advantage of Subversion’s ability to be smart about merges and save you from encountering a conflict for every line that was edited, then you should use the trunk and branch method. You’ll encounter a huge amount of pain if you try to merge two projects that don’t share a common revision in the repository history.

You should put your original code on the trunk and each create a feature branch from the trunk. Don’t try to merge changes between branches. When one of the branches is complete, it can be reintegrated to the trunk, and the other developer can pull the changes from the trunk. See task 27 of the book for more info.

  You must be logged in to comment