As some may have noticed, I migrated nearly all my projects in the last year from Subversion to Mercurial (and GIT). Step by step, as I am rather conservative with changing to new technologies, particularly when they are at the heart of the project. And changing the SCM is sort of a surgery on the open heart.
However, after nearly a year of experience I must say, SCM was (for me) never easier and more enjoyable than with distributed SCMs, particularly with Mercurial. Excellent documentation, easy and straightforward to use. Yet these days I was asking myself: If I would have to name one outstanding feature that would convince me to change from a centralised system like Subversion to DSCM, what would it be?
The answer might be surprising, but for me it is clearly this: No headache and fear when working with the repository any more. What do I mean with that? Well: I was never a Subversion guru and everytime I needed to do an operation I did not do very often (branching, merging) I was sweating. Should I press the button, am I making a mistake? What exactly do these options mean in the SVN client? Did Eclipse now mess up the local copy? Should I commit? After all, you are always working with the repository. If you mess up, you have a problem, and all team members with you. Not a nice procedure.
But with a DSCM there is no master repository, hence in case of doubt I make a clone, play around with the clone. Should I mess it up, I delete the clone and nothing happened. If everything is fine I push the results. This is for me personally the most essential feature of systems like Mercurial. I can play around even with esotherik plugins and features without the fear to destroy anything. This also makes learning for new users way easier.
What is your opinion?
1 comment:
Playing around with the repository locally and not messing up everything for the other developers is also one of the key benefits for me.
What I like even more is the ability to setup repositories extremely quickly and without the need to have a separate location for the repository itself. What I did not do in the past but doing now a lot, is to create repositories even for the smallest demo projects or spikes I'm working on - the safety net to undo changes was very helpful in several circumstances....
Post a Comment