Programming poll
Ok, so I'm trying to get our team moved off a "home grown" version control system that really sucks balls to something a little less buggy (ie. doesn't core dump if you have an apostrophe in a commit message) and a little faster (takes less than 5 minutes to check in a dozen files). And no, I'm not exaggerating. It really is that bad
( Read more... )
If you need further convincing, try doing this sometime in a centralized vcs. It gets ugly very quickly, and dvcs handles it remarkably cleanly. In my experience (3+ years using dvcs in professional software development environments, 9+ centralized) distributed is hands-down more powerful, more flexible, more manageable, and all around a better fit for professional software development.
EXCEPT (and this is an important one):
You have to get it. You have to get how distributed works and why. And so does the rest of your team. If the team doesn’t get it, they will screw it up. Code will get lost or mismerged or forgotten or never get pushed to a shared repository, and some recalcitrant teams will even blame the distributed model itself. The problem is that they’re trying to use a screw as if it were a nail. You can try to bash in a screw with a hammer and it might not mangle your project too badly, but you’ll get much better results if you learn the right way to work with the tool. That said, if your team really insists on bashing and can’t or doesn’t want to learn the new techniques, it could be trouble.
All that said, since the first time I used hg three or so years ago, I’ve strongly preferred it and used it for all of my personal projects without exception, and I’ve pushed to get work projects moved that direction wherever possible. I’m a complete convert.
Reply
The real challenge will be to integrate this with the beast that is our current VCS, a thing called "BDM". Here's a description of it I posted on Facebook:
Currently we're using a rather hackish system that's indescribably painful to use. We're doing this because the design team we work with has this particular system baked into all of their workflows. It has all sorts of wonderful quirks:
* Crashes with a coredump if you use an apostrophe or certain other punctuation in a commit message.
* Takes minutes to check out groups of files to edit. And, you can only edit files if you check them out, and all checkouts are exclusive checkouts. Cost of a checkout goes up dramatically in the number of files getting checked out in parallel.
* Takes minutes to hours to check in files once done editing. The expense goes up dramatically as a function of the number of files modified and operated on concurrently. Thus, you have to segment your large checkins and large submits into many small batches if you want them to finish this quarter. And checking in isn't enough: You have to submit your checkins after checking in and both checkin and submit are similarly expensive.
* Making a new release can literally take hours. Note that releasing does not involve building anything. All this time is just spent managing symlinks in a UNIX filesystem, making remote database connections, and moving existing files and filesystem metadata around. It really is nothing but a paper-pushing exercise, all internal to the computer and the network.
* Workareas only contain symlinks to read-only copies of all the files by default. To change a file, you have to check out an exclusive read-write copy first. You can imagine all the breakage this can cause. For example, we tried to manage a perl library tree inside this scheme with CPAN. I'm still searching for adjectives to describe the level of failure achieved.
Yeah, broken as all get out.
(When I say "goes up dramatically", we're not sure if it's quadratic, cubic, exponential or what... None of us is so patient to figure out what the crazy factor is. We all just Ctrl-C the operation, and write a quick ad hoc script to operate on files in batches, or just go home and check back in in a couple of days.)
Ultimately, if I can move our team of 5 off of BDM, I will still have to write some bridge scripts so that our stable releases get pushed into a BDM repo somewhere, since that's how the design team next to us will pull our releases. Unless we can talk them into doing a "git clone" instead (which seems unlikely). If I can demonstrate superior productivity with better revision control, then perhaps I can slowly start getting folks in design interested in something that doesn't remind me of the Festrunk brothers' vacuum cleaner whenever I use it.
Reply
Leave a comment