Preferred Version Control Methodology

Question

I am a novice in the world of source/version control and I have been doing as much reading as physically possible to get my head around the different techniques that people use for their own source/version control.

One thing that I have noticed is a pretty distinct break in the methods of developers into two (possibly more?) groups: one group prefers to keep their trunk in an always-stable state and performs all maintenance and future development in the branches, while others prefer to do all of their development in the trunk and keep it in a not-so-stable state.

I am curious as to what the community here at StackOverflow prefers or if you have your own methods.

Note: If it would help tailor the answers, I should note that I am a single developer (at most there would be two or three others in the same project) who works primarily in ASP.NET and SQL Server 2005

Answer 1

I'm in for the always-stable trunk. You need to be able to rebuild the latest stable version at any time...

Answer 2

In your case, I'd strongly recommend avoiding a lot of branching. It's really a fairly advanced process and not necessary for small projects and small teams.

Answer 3

Always stable. Even if I'm a single developer -- almost especially if I'm a lone developer.

Having a broken tree to me means one less way to know what I should be doing.

Big changes go in branches, as well as stable releases, and do the smallest unit of changes possible at any given point so as to keep moving forward at a good pace.

Answer 4

I do all my development in the trunk. I'm a single developer and don't want to deal with the hassle of branching. When my code is stable I just tag that current version. For example I'd tag version 1.0, 2.0 beta, 2.0 release candidate 1, version 2.0, etc. Branching would probably a better alternative if you’re maintaining old versions for bug fixes and support but since I don't do this I don't worry about it.

Answer 5

The differences may have to do with how painful merging is or isn't in a given version control system.

With git, branching and merging is practically effortless, so it's a common workflow for me to keep my master clean and do all my work in branches. Branching and merging in svn, particularly in previous versions, isn't quite so cheap and easy, so when I was using svn I tended to work directly on the trunk.

Answer 6

I've always used the main trunk as head of code. Generally new development code goes in there.

We branch for releases and we may branch for a "big" destabilizing experiment.

When we make bug fixes they go into in main first and then they get merged (back-ported) into the appropriate version branch if required.

If the big experiment works out it get's merged back into main.

We use tags for build numbers in the version branches and the main. That way we can get back to a specific version and build if we have to.

Answer 7

Try and keep it simple to start with, I always try to have a known working build that can reproduced for testing and deployments etc. Depending on your repository you could use revision number (SVN), or just label the known working versions as they are required.

If you find you have multiple people touching the same files then you will need to consider a branching strategy, other than that for such a small dev team it will just be un-necessary overhead...(IMO)

Answer 8

This is the methodology which we follow: Any stable release should be taken from the trunk. Any further work or modifications should go inside the working branch and should be merged with trunk when ready to release.

If have multiple independent developments, each group should have there on branch which they should sync with trunc periodically and merge it back to trunk when ready.

Answer 9

As I'm sure you've noticed from searching the web for answers on this topic, this is one of those things where the best answer is "It depends.", and as most of the responses have indicated, it's a trade-off between how easy do you want to be able to commit/merge new code vs. managing an extensive version history that you can easily roll back for support or debugging purposes.

I work for a small company, which means that at any given time, we could have 3 or 4 different versions of code on developer machines that have not yet been committed to the repository. We use TortoiseSVN for our version control system, which gives us the ability to branch/merge without too much difficulty, as well as being able to view the update log or revert our local copies to an earlier revision pretty easily.

Based on your question, I suppose we would fall under the group of developers who attempts to keep, at all times, a stable Trunk, and we branch new code and test it before merging it back into the Trunk. We also make an effort to keep "snapshots" of each version release so that, if necessary, we can easily check out an earlier version and re-build it, without incorporating any new features intended for a future release (This is also a great mechanism for tracking down bugs, as you can use earlier versions of code to help determine when a particular bug was first introduced into your code. However, one thing to be careful of is if your application references common code that is maintained separately from your version-ed code, you will need to keep track of that too!).

On the repository, it ends up looking something like this:

• Trunk

  • v1.0.1.x Release

  • v1.0.2.x Release

    • v1.0.2.x Bug-Fix A <-- (These get merged back into Trunk, but remain on the repo)
    • v1.0.2.x Bug-Fix B

  • v1.1.1.x Release

  • v1.2.1.x Development <-- (This will get merged back to Trunk, and replaced by a Release folder)

    • v1.2.1.x New Feature A <-- (These get merged back into the Development branch)
    • v1.2.1.x New Feature B

When I first started at the company, our version structure was not quite as sophisticated, and in my experience, I would say that if you have any need whatsoever to keep track of earlier versions, it is will worth the effort to put something like this together (like I said earlier, it doesn't have to look exactly like this, so long as it fits your individual needs), keep it well documented so that all contributors can maintain it (the alternative is that the creator ends up "babysitting" the repo, which quickly becomes an incredible waste of time), and encourage all your developers to follow it. It may feel like a lot of effort in the beginning, but you'll appreciate it the first time you need to take advantage of it.

Good luck!

Answer 10

One aspect is how long will the changes be in an unstable state.

When a change I make might affect other people, or the nightly build, then I do my work on a branch, and merge when stable.

When the changes I make won't affect other people (because it is my private code at home, rather than code at work), then I'm OK with checking in non-working intermediate states if that's what I want. Sometimes, I'll make a few checkins in a row which are not stable; that's OK for me when it is just me who is affected and the workflow will be continuous. It's if I come back in a few years time (as opposed to just a few days) and things aren't working that it gets problematic (one disadvantage of having been around as long as I have - I do have some projects that are still in development and maintenance that are old enough to vote).

I use a variant of tagging to achieve repeatable builds - so if I need to go back to a stable version for a bug-fix, I can use the tag information to do that. It is crucial to be able to get a stable version on demand.

Answer 11

For SQL, you can use a third party tool as - SQL VERSION CONTROL

Answer 12

One key distinction is how big files tend to be on average. Big files (1000 lines +) tend to have many independent changes that are trivially automatically mergeable. So the fact that someone else is actively changing a file you are about to start work on is probably uninteresting, so it is ok if the system makes that hard to discover.

So you tend to end up a VC strategy that has a lot of branches, and easy merges. New functionality is written in new branches.

If you are working with the smaller, highly-cohesive files typical of an OO design, in a language like Java, such accidental conflicts are a lot rarer. Even as an artificial example, it is pretty hard to come up with two sets of changes that can be made to a class (and corresponding JUnit test cases) that can sensibly be made in isolation and then automatically weaved back together by a text merge tool.

If you do a lot of refactoring (renaming and splitting files) then that stresses out the merge tool even more.

So you tend to be best off with a VC strategy that has an identifiable and usable stable trunk and minimal branches.

In the first approach, new functionality is written in new branches, and merged when complete. In the second, it is written in new files, and enabled when complete.

Of course, if you do the second, you definitely need strong protection from the baseline becoming unusable for any length of time (i.e. continuous integration and a strong automatically-run test suite).