Help with ClearCase to Teamforge Subversion migration!

Hello both,

We are also looking to do the same!

I have a few questions for you:

What size development teams do you guys have?

How many projects do you have on the go at once?

Do you have any large development projects that require interproject deliveries as they all modified shared/common code?[/ul]

What sort of analysis/investigation did you do for migrating?

And what were your reasons for moving?

How far have you got so far?

Thanks,

Hayley

Hi,

Have you guys thought about the Use Case that you will employ for branching? This Subversion Branching is rather different than ClearCase (even more so than UCM).

Bob

The Subversion "reintegrate" branch merge strategy is fairly similar to the UCM model: create a branch for team, feature, or developer; work on that branch, occasionally merge out from trunk to stay current; eventually merge back down to trunk to deliver your work to the release stream.

For more details, check the Subversion book, http://bit.ly/hQgbCW] Keeping a Branch in Sync section.

I used ClearCase for ten years or more, even worked at Rational for a while. I'm very aware of the power of the advanced features, and I'm not at all claiming that Subversion is point-for-point equivalent.

But at the same time, I'm also aware of a lot of limitations of ClearCase. It's very expensive in terms of compute resources and administrative support, for example. Some of the coolest features end up not being used at all, in many shops, because of platform compatibility issues (compatibility, incompatibility, and inter-compatibility), or problems when people take their laptops out of the network, or evolutions in language-processor design that violate the config-rec model. High-power items like config specs can be a lot of rope, and we've all hung ourselves more than once. Delightfully visual representations like the version tree can knacker the server(s) in no time.

The Subversion community began with a notion of how to do branches and tags really cheaply. In as much as I once worked in a large, globally distributed ClearCase shop where we had two engineers fully employed, 24x7, just making release tags, "cheap tags" gets my attention! With Subversion's cheap tags, you can safely tag what goes *into* a build, and let the build and test cycles tell you whether it's any good. And if it's not, you can safely remove the branch or tag, or file it away in some subdirectory where it needn't distract people--whatever fits your process--and none of these tag creations and adjustments need take longer than five seconds. Ever.

An additional advantage that should interest this audience is that the "global revision number" (which is the heart of the cheap-tag secret) is also a "global change number," suitable for tracking purposes in a sophisticated CM system. The appropriate Subversion commands can take either a "--revision REVISION" flag (which means "the that-version of everything") or a "--change REVISION" (which means "just the changes that went into that one commit"). In this way, the revision/change number can be tracked, reviewed, applied to related branches, and all the other change-centric stuff that can make a real difference for the CM process.

It's certainly true that ClearCase, as the latest product of over 30 years' evolution, has a head start over Subversion in some areas. CollabNet has attempted to help out, by supplementing the community's core contributions, with such add-ons as branch-and-merge wizards, change-based tracking tools, and the like, but there are still some holes and rough spots. But some of the simplicities are intended: just because you want something, such as change-tracking, does not necessarily mean you want to spend an arm and a leg to get it. A little rethinking about how you really want to use changes, a novel tool like cheap tags, and you may have a better solution than you did before. Different, yes. But better.

Too bad on going to SVN from CC. CC works just fine with the Remote Client for remote users, just like subversion. I see going to SVN as a backwards step and will require the installation of many other tools to maintain the working ENV that you had. plus you will need to add a UCMSVN tool (Exists on Collabnet) to get anthing approaching the fantastic branch management that UCM provides. I know this since I created a large scale ENV still inuse at a major insurance company (1000+ vobs Using a top level PVOB with child PVOBS then VOBs to handle the inheritence. contact me if you need help with the CC to SVN, I've done that also but not with the tool, I wrote my own, just CC scripts then imports to SVN, very straight forward.

Having been at the ground floor of both UCM (I was on the field advisory team working with Brian White on its design) and Subversion I can talk to them both. UCM was designed to be an automated process that would abstract the complexities of ClearCase from the average user. Originally, we hoped to make it more customizable, but that never came to fruition and so you have a very set process. When you automate you basically have to make assumptions as there is a lot that the user knows that automation can't know. For UCM, that meant that anything anyone was assigned to work on would require a stream (only slightly more than just a branch) whether that work really needed isolation or not. Obviously the user or their lead would have been able to make a decision on whether that made sense or not based on knowing what they would be doing.

Because of that automation, it is very important to support not only the idea of branching for isolation, but also the ability to merge the work on that branch with that "published" (i.e., delivered in UCM terminology) by others (and therefore on the integration stream in UCM) as well as be able to merge the "published" work to the "development" branch (i.e., rebased in UCM lingo). The automation drove the need to do these things frequently since all development was by definition isolated.

That model, while simplifying ClearCase, is actually quite complex and constantly hitting the operation most developers want to avoid, merging (or more accurately they want to avoid making the decisions on conflicts). So when you look at development outside of that automated implementation, this model is rarely appropriate for development. Rather a model that isolates work when there is risk rather than just when there is work is more logical and lessens the complexity. It really goes back to a logical best practice that says when you are changing tools, go back to the core requirements and build a process that best utilizes your new tool. Taking a process and trying to make it work in a new tool isn't a good idea. That isn't because it may not have been a good process with the legacy tool, but it was designed to take advantage of the best of that tool and avoid the worst. That's very true of UCM and ClearCase.

Now can you accomplish UCM with Subversion? Yes, but obviously Subversion doesn't have the automation to put it into place that ClearCase does. Subversion is designed to allow the organization to determine their process and makes no assumptions about an out-of-the-box process. Keep in mind that part of why Rational did that with UCM was in reaction to the user pushback on complexity which isn't an issue with Subversion.

In the spirit of being open and direct, it is important to note that Subversion has difficulty with repeated deliveries from the same branch. Subversion's initial target was to replace CVS as the de facto open source, centralized version control tool and CVS had no merge tracking. ClearCase was designed to be an improvement on the work that the development had done in developing DSEE which had merge tracking. Subversion added the first phase of merge tracking in 1.5 and that's no small feature to add so there were going to be limits and this is the main one. Subversion provides great functionality (reintegrate) to handle the merge of a child branch back to the parent when the parent contributed to the child, but the algorithm can't handle the situation where it has been done previously. The work-arounds are to either delete and recreate the child branch to continue on to the next "delivery" point; or you can immediately do a manual merge back to the child branch (assuming no other changes were made on the parent branch). This is something that is targeted to be addressed in one of the next couple of releases.

Subversion has a very powerful and simplified branching model that doesn't have the scalability issues that legacy tools have. It allows for you to quickly and easily isolate work while tracking what you've merged and haven't merged. Organizations have successfully and happily moved to it from any version control tool you can name.

Hope this helps,

Bob

I have recently decided for the group that I work in, not to migrate from CC to SVN.

The whole hierarchal branch model limitation of SVN is a showstopper. Not too mention other limitations like no partial branches etc.

If you come CC think twice before going down the road of SVN.

Just my $ .02

Hayley wrote: "How does Subversion cater for large development projects where you have multiple developers changing the same file at the same time and frequently perform deliveries and rebases (more than twice daily)? We also often deliver between UCM projects so the changes can be reflected in one of the later releases of the project - can it cope with this?"

The most accurate answer would be "differently" ;-)

Even in UCM, if you're rebasing and delivering "more than twice daily," it may be that the branch-centric UCM model is getting in your way, and a bit of flattening might be in order. UCM's reflex is sometimes a bit over-eager to branch. If various developers need to see each others' work twice a day, they might ought to be on the same branch, directly, and let the working copy (or "snapshot view") constitute the personal sandbox. That would be the Subversion reflex, at any rate.