First Experience With SVN Merge Tracking
First Experience With SVN Merge Tracking
Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
Source Control has really crawled forward at a slow pace. I am going to be a total contrarian (read: jerk) and say that the arguments I made about reactionary kerfuffles being the norm in open source go double where SCM is concerned. Consider: I started with SourceSafe. Going from that to CVS was like getting out of jail. Seriously, like crazy huge improvement. I would put that at a couple orders of magnitude improvement. When Eclipse first hit, it's support for CVS was outstanding. I remember in 2004 going to eclipsecon and talking to the 2 guys who did the CVS support and the main thing I was looking for then was an easier way to do merges. Of course, like most of the rest of the world, I ended up dumping CVS not long thereafter for Subversion. Then some years passed, and the problems svn solved, mainly making it easy to move things, were bought at the cost of horrendously bad plugins that finally stabilized a few years on (use subclipse now, which is pretty good). Then svn started talking about lightweight merging, what I had been after all those years ago.
The idea is kind of simple: people don‘t branch because they think they are going to end up with 2 messes instead of 1. Wouldn‘t it be nice if you could make a branch and keep it in sync while it was out? That‘s the dream. The reality, however, is that merge tracking doesn‘t really give you that. Although it could.
If you want to use merge tracking, you really have to get everyone on the team familiar with it before you go off and make your branches. We have been trying to release from branches, based on the logic that if we release from a branch, we can avoid the last minute hell of people trying to do massive merges right before release. Instead, we can test a merge and then if it doesn‘t go, release off the branch and have all the way until the next release to stabilize whatever didn‘t make it from trunk.
Recently, though, I decided to convert my iPhone app to a universal app and of course thought: let me do this on a branch. Sure enough, one of the other people on the team had some issue using my new branch and went back to work on the old one. Next thing we know, we are a few weeks off shore, knowing a really sucky merge lay between us and solid ground. Last night I tried to do it using svn at the command line and it was really not pretty.
In a lot of ways, you can‘t blame svn for not offering much to people who have not toed its line. The idea behind merge tracking is that once you have 2 branches, when someone changes, those changes should go onto both branches. We probably would have had zero problems if each dev had followed this. But, wait, it‘s freaking 2010. Are we still saying ‘sure you get expected results, if you volunteer for all our behavior constraints?‘ [I call this the mickeysoft plan.]
Let me drift off the reservation and imagine life in an alternate reality, one in which the head of the pantheon would be Bertrand Meyer. Imagine that there was a simple way in the repository to associate the two branches, then when a commit is done, it would be mirrored to the other branch automatically. Then you wouldn‘t even really need tool support. I would just say ‘ok, commit my stuff,‘ and SVN would return its list of conflicts. Where they are is pretty much immaterial. I perform the merges and go on my way. This is one of the endemic problems of open source: most of it is based on NO model, or a model that represents only a tiny corner of some bubble reality. Procedural coding is not only bad because its weak capacity for abstraction results in it bleeding out under the lightest of loads, it sucks because it screams ‘let me get about my business‘ and the ‘my business‘ in reference here is always some little trick rather than a true accounting for what can and should go on in the environment. The first line from the SVN book about merge tracking is ‘the implementation of merge tracking is insanely complex and you have almost no window into it.‘ Here, let me offer my translation services: it‘s a pile of crap that deems itself accountable to none (of course, given that we know it is written in C, this warning label was scarcely needed).
I found an interesting post on Stack Overflow where some rube came in to ask what was better about Git and the main answer was 'it's great when you can't attach to your server' (file under: could care less). But I am guessing that Git would be better able to deliver real merge tracking due to the fact that it has modeled reality a little bit better. Distributed models are not just for offline crap. They decrease complexity through a number of mechanisms: 1. they model the actual world more accurately so there is less fitting and trimming required, and 2. they, um, distribute it (the complexity). Does Git make it easier to branch? to recover from bad merges? to rollback offending commits? It would be interesting to see some real metrics on this. I believe that a study of these practices industry wide would be shocking. I bet that most teams rarely branch, almost never do lightweight branching, and that, even though this was the only major feature from svn in the last 5 years, almost no one is using it (there is pretty much zero tool support).
Opinions expressed by DZone contributors are their own.