![]() I can't tell you how absolutely grin inducing the current system is when developers do things in a few minutes that used to take hours or days. As a result, the "It works on my machine" excuse is almost completely invalidated. Lastly, this prevents the temptation of distributing builds built on a developer machine. I always have the ability to compile locally if I'm developing A and D at the same time (utilizing local publishing), but the base case is easy. Thus I can ask for a change in A, and have it be available - automatically - in about an hour for consumption by D. *All dependencies are built automatically on a built server using continuous integration*Įvery push for every project kicks off a build in Jenkins. It "Just works"ĭuring development we utilize the last main benefit that I'm going to go over: ![]() Now, those versions, in binary form, are controlled so I only have to update D to the tag I want to base from, make my patch and republish to Artifactory. I would have explicitly control the version of B that both D and C needed. In Clearcase, I would have to recompile A, B, C, and E to make a patch to D. ![]() That is to say, my project D depends on E, B and C. We had no StarTeam admin, but only a small development staff (| For those familiar with StarTeam it may surprise you that it was actually much much better to actually work with than a huge Clearcase system. But that was the Clearcase lineage and it didn't change much over the next several years.Īfter I left that engineering firm, I went to go work for a corporation where we used StarTeam. It was, in short, the dark ages and it would be an unfair comparison to compare 2001 Clearcase with 2010 Merurial. This was, however, only 2001 and Clearcase was still considered "best-of-breed" (which is market speak for "this isn't innovated but worked 5 years ago"), Subversion was new and envied by our developers and was trialled on small projects, and Linus was proselytizing about the benefits of BitKeeper and would soon switch over Linux development to the first widely used DVCS. If you wanted to roll-back to a previous version of the VOB you would have to check-out (lock) files on a file-by-file basis to the particular version you wanted, or modify the config spec and wait hours (!) for it to apply the new rules to our huge, huge VOBs. In convoluted syntax, it basically said "show me this version, from this base date, unless this version is present on this particular branch". The config-spec is a special file that describes what view you will be presented. Operations took forever to complete and I never once rolled back my dynamic view to a previous state because our config-spec was too complex. When the network performance wasn't up to snuff, there wasn't anything that you could do in that mounted VOB. It worked well for well-oiled VOBs (or versioned object base, the Clearcase concept of a repository) on small low traffic networks, but on our *very* large internal network, the performance suffered miserably. Every other week we'd have minor network issues that would bring Clearcase to its knees.įor those who are not familiar, dynamic views are a virtual directory that is kept in sync with the central repository via an file-system level driver. We worked off of dynamic views and the user experience was abysmal. We had a large multi-site Clearcase installation, along with several (!) full-time Clearcase administrators. We were a very conservative organization who targeted a variety of Unix, namely HP-UX and SunOS. Old-school as in my aisle mate still had his first PC that he was assigned around 1980 next to his newer workstation. ![]() The first was an old-school engineering firm. I have, however, worked at two very different organizations were it was being used. I regard people who say that they are with the same apprehension as C++ "Experts". I'll be the first to admit that I am not a Clearcase expert. I don't pretend to think that this is "The right way" for everybody, but rather "Here's what worked for us." Not all of the improvements we made, however, were directly related to a VCS. We moved away from Clearcase because it was broken and picked Mercurial over Subversion. Transitioning from Clearcase to Mercurial I apologize in advance for the wall of text. ![]() I considered posting the html version but it seems that most people here prefer monospaced (I've instead attached the html version). This was written using reStructuredText because I'll probably publish it somewhere eventually (right now I don't have a good spot to do so). Here I'd like to document our experience and try to outline exactly why we think our development process is so much better than what it used to be. I promised a longer follow-up and unfortunately it's taken me too long to actually get back around to it. Some time ago I posted to the list about several small parts about our experience transitioning from Clearcase to Mercurial. ![]()
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |