Merging with GIT is quite simply the most beautiful action I’ve every attempted. Even more so after the SNAFUs that have been caused with Subversion. This not to say there is anything wrong with Subversion. I think with all of the debates of GIT vs Subversion or why use GIT over Subversion kinds of misses the point of SCM. This is a topic for another blog post and one I’ll unlikely ever write. Debate somewhere else, certainly, but meh, I might write it at some point.
How SNAFUs Are Born
User error. That begs the question of the best way to use Subversion to minimize the impact of SNAFUs. I think if all you are ever going to do is commit to trunk without ever branching or tagging, then you’ll do fine. The reverting and history tools are great. However, in business and large projects, problems are borne from branching and not using the best practices of Subversion. This is however a topic for another time, perhaps in Part 2, where I will go over possible branching methods.
What Are Best Practices?
I really don’t know all of them. I only know the ones I remember from my readings and from personal experience and from the work place. Someone more experienced and a veteran of SCM will have more and better ones. For the sake of my personal explanations to why you don’t do something a certain way, I’m just going to explain it this way. If I’m not doing a good job and you have improvements, then please say so. I would rather use them for my personal benefit for teaching newcomers to Subversion.
Really, given the work place fast pace environment, it is difficult to say, “Create a new branch for it.” When it comes to Subversion. I know that some would say that the cost isn’t that high, but when the repository is 1GB download, branching becomes a serious PITA. Also, if it is easier and quicker to not create a new branch, even when one is required, then a new branch is not going to be created. These really are best practices for branching and when branching isn’t used as much as it should.
- Always Merge Revisions That Haven’t Been Merged Before Yours
Damn, I can’t explain how many times this simple advice was not taken and how many SNAFUs it has created with Subversion. I tell people this again and again and they don’t get it and wonder why everything has gone to hell.
…Except that this is not a perfect world and people do not always create a branch for stuff that could not go in immediately. This means the responsibility of the person committing a simple fix in a branch has to take up with original person who committed the revision that can not be merged for one reason or another. This is partly why branches should be created, but knowing when a new branch should be created is not always easy. If this is the reason, then certainly talk to the person and get to testing and working around the problem.
One action that should not occur is just going ahead and merging and committing the revision anyway. One caveat to this is that if the prior revision that wasn’t merged does not touch any of the files that the revision being merged modified, then it can safely be merged.
- Commit Additions, Deletions, and Modifications Separately
If you do, then you’ll never have problems with having to go back and commit revision dependencies.
Given that this advice is not going to be taken seriously, it is a sure bet that the realization of why you should do this will become very clear when the first SNAFU comes into play. I will also say that for a while I haven’t done this and it has bitten me in the ass enough times that I’m starting to take this advice myself.
A better way to put this is never commit an addition with modification and the reason will be clear after a few revisions when you only want to commit a modification or addition. The problem is that merging a revision merges everything in that revision[1]. The problem with modifications is that usually the reason it wasn’t merged in the first place is that it wasn’t ready to be merged and those modification revisions accommodate. If you have additions to one of those modifications that are not ready and need to merge those additions to the trunk, then in order to complete the merge, you’ll need to also go and merge all of the revisions that haven’t been merged that also had modifications for files in that revision and also in the revisions that you’ll need to merge.
If you always keep additions separate, you can merge those without fear of merging something that should not be merged and keeping track of all of the revisions that the modifications touch.
- Rule of Thumb for Branching
If it will take more than one day, create a branch. If you are unsure whether or not the modification will be accepted, create a branch. If what you are doing is highly experimental and might break anything, create a branch. If you are refactoring major parts of the code and know that only you will be working on it and will go live after you are finished, create a damn branch! In fact, unless you are making a minor change that is going to be merged immediately and doesn’t belong in an already created branch, then just create another branch. Just for shits and giggles, if you have the time and it won’t screw anything up, create another branch.
The problem is that too many times, at my work at least, the expectation was that the change would go in immediately, but plans changed and it could not. All of a sudden you have a ticking SNAFU bomb just waiting to go off, unless it is in its own branch that no one else is working on. Even now, there are revisions that can’t be merged for one reason or another and I cringe every time I see those revisions. Luckily, they affect only a small area and the impact is very small, so much so that you could just think of that area as its own branch since no one enters that area.
- Commit Often
Well, I don’t have the full explanation, but it is very good advice for those that use it. The gist of the advice is that if you commit often then reverting or going back to a prior change won’t having a huge impact to the other parts of the code. The other part of it is that you’ll want the history of committing new features. Having many small commits helps with merging and minimizing conflicts when merging.
In my personal experience, given the overhead of committing using TortoiseSVN, in the 3 to 4 years of using Subversion, it has only bitten me once. Really, I understand in part the rationale for doing this and I do follow this advice sometimes when I’m using GIT, but until the cost for committing in Subversion becomes cheaper, I don’t think I’ll be doing this.
I added this because well, any best practices wouldn’t be complete without it.
Footnotes
- This is not completely true, it is possible to merge a single file in an revision. However, for the purposes of simplification, it is better to always merge a full revision. I do know that in 1.7 of Subversion, the need to do this is minimized. However, the amount of problems with merge-info and reintegration and merging is painful enough to just always do it this way.
Possibly Related Posts:
- Game Engine Development and Open Source
- Plans for Base CMS
- Project Plans
- Calibre Improvements Part 2
- Usability Testing Software Development
Comments are closed.