Subversion - Branching / Merging

Question

I have a basic grasp of branching and merging in SVN. You branch, do whatever, merge back to trunk.

Do you have to merge back to trunk?

My scenario:

I have a small applications in ASP.NET MVC2, using Linq to SQL. With MVC3 out, I'm gonna either upgrade it to MVC3 or redo it from scratch (using EF 4). In either case, the next "version" is going to be very different from what I have now.

I'm wondering how I should handle SVN part. Should I put it in SVN as a branch of current repository (/svn/project/trunk/mvc3) or should I start a new repository(/svn/project_mvc3/trunk).

Answer 1

This very much depends on what you want to ultimately achieve with Subversion. Version control enables you to track changes between iterations of development. At its most basic level, it enables you to rollback to a previous version of the code and effectively undo changes.

It sounds like (apologies if I've misunderstood) you consider version control to be a storage medium for your code, but it can be much more than that. It is at its most powerful when multiple users are making changes to the code. Branching, in part, gives you that functionality.

In answer to your question, if you consider that your code will evolve from its current version to a new version (albeit with a major architectural changes) then version control will give you the functionality you require. If you are replacing the application wholesale, then I question whether tracking history within a version control system is the correct solution.

If the two versions of the application are fundamentally different then it can be argued that they are not the same application although the end point is the same. If they have common code and will slowly move to being a different application, then version control would be a possible solution.

So the answer to the question is probably: "It depends". What does version control do for you? Why have you put the application in version control in the first place? If the answers to those questions still apply to the new version and, critically, apply to the evolution of the application from one version to the next then branching / merging is probably the right solution.

Incidentally, if you are the only developer of the application, then there's really no need to branch and merge unless you need to maintain the trunk during the period that the branch is in progress. This may be the case if the trunk is in production somewhere and you need to apply bug fixes while you develop the branch.

A final (if a little tangential) point is that a branch and the trunk are basically just subfolders within Subversion. You can merge either way (trunk to branch, or branch to trunk).

Answer 2

If you want to keep what you currently have but will be performing significant changes that you want to use moving forward, I would suggest creating a branch for your current project and put your new changes into trunk. For example (/svn/project/branches/mvc2) could hold your current project, and (/svn/project/trunk) could be MVC3 moving forward.

Answer 3

Keep it in the same repository. Source code history doesn't respect “versions” (releases) for humans.

Once an app reaches the routine maintenance period in its life cycle it's a usual scenario to create a branch for maintenance of the stable version, and keep developing the upcoming version in the trunk. Generally, every time you make a public release, you should make yourself a branch.