Single Code Line consists in having only one version at a time. That means that you won't have different branches with different features and you'll avoid the whole messy merge-this-branch-with-the-other task. Adding new features does not require a new branch: it is incrementally added to the existing version.
Having only one branch at a time really makes continuous integration a lot easier. On the other hand, if for some reason you want to release an older version (let's say your client requests) you'll not be able to.
Many branches simultaneously being developed are a risk factor because merging can generate new bugs and there's always a need to test the merge itself (unit testing and TDD are handy). Besides that, if you're working in an Agile team having different people working in different branches contradicts the collective code ownership (http://guide.agilealliance.org/guide/cco.html).
Recently I read here that Workday adopted this technique along with weekly releases and they made some really good points (I'm not going to focus on the weekly releases points in this post but it's worth checking the link):
- How bad is it when you are developing in a new branch and suddenly you have to correct something in the production branch? You have to correct in the master, merge with the new branch and test in both!
- It's the end of the features that are developed and have to grow beards before going to production! If there's only one version, chances are no features will be forgotten along the way in branch number 43.
I think that Single Code Line is very useful when your release dates are not very apart from each other. This way, if/when the client wants to change something, there's not been a lot of work upon the release. If the releases dates are very apart, the client will notice a lot of changes simultaneously and chances are that there will be more corrections to the branch or even some undos. Since there is no previous branch, it might get a little messy.
However, specially if you are maintaining code, Single Code Line might not be a good solution. Release dates are often more apart and if the client demands an older version you won't be able to deliver.
My ideal solution would be a hybrid between branches control and Single Code Line. Maintaining a lot of branches is confusing and error-prone but Single Code Line doesn't allow you to save the last "stable" version. What I think is a great solution would be Single Code Line along with one more branch: the previous production version. Everybody would work upon only one branch (the latest stable production version), no feature would be forgotten along the way and tests cases would only incide in one branch (no merges, etc...). On the other hand, the last production version would be saved in another branch in case the client requests a rollback until the new branch that's been developing is released and accepted. No more than two branches allowed.
