CODEWITHSUNDEEP
svnversion-controlclearcase
rahmu
rahmu

Reputation: 5878

Managing the shift from ClearCase to SVN

I'm in charge of the move from ClearCase to SVN at work and I'm looking for help in defining a proper workflow for the team. We work on a VERY large code base with around 50 developers working in 3 different sites. I'm part of a team dedicated to the repo. We're not developers, but our job is to merge developments package next releases. And none of us is familiar with svn.

Our current workflow on clearcase:

  1. dev creates a dedicated brtype (that will be instanciated for every element they checkout)
  2. dev creates a view pointing to the latest version in 'main' branch
  3. dev codes and checks in his changes in his branch
  4. once a month assmebly team (us) create brtype+assembly view
  5. In our view: Merge, compile, release
  6. Once it's released, merge to main branch
  7. repeat

Under SVN, we would not be able to do this. My primary concern is disk space. If every dev creates a branch for his devs, we will run out of space in week or so.

SVN workflow (proposal)

I thought of using the 'patch' command (we work on unix).

  1. Dev checks out (read-only) the main trunk
  2. Codes. Generate a patch. Sends it to assembly team.

  3. Assembly team co. Apply patches. Checks in.

  4. repeat

My question is is this a plausible workflow? If it is what tools could we use to:

I should stress that I'm not interested in the migration of the repo itself. It's already taken care of, and well documented. My question is... where do we go from here?

Upvotes: 1

Views: 255

Answers (2)

VonC
VonC

Reputation: 1323803

You can see an (old but still relevant) IBM article on the differences between ClearCase and SVN

The saving grace is that the 'copy' is a very cheap quick operation, so you can create a branch or a baseline/tag in constant short time, regardless of how many elements you are affecting.

Compare this to CC, where creating a branch is effectively a zero-time operation (thanks to lazy branching managed in the config spec) but the normal baselining strategy is an expensive operation of labelling every element - but where you can see a full version tree of any directory or file.

So your original workflow still stands, you just need to be careful when you merge back into trunk.
See Advanced merging (with the latest SVN 1.7), where you need svn merge --reintegrate.

Upvotes: 1

thiton
thiton

Reputation: 36049

Under SVN, we would not be able to do this. My primary concern is disk space. If every dev creates a branch for his devs, we will run out of space in week or so.

Copies in SVN are cheap because only a diff is stored. Your patches would have the same disk impact. You could easily work identically to the clearcase workflow.

Upvotes: 0

Related Questions