I was wondering if anyone has recently migrated from ClearCase to Subversion, or if anyone has been looking into migrating?
As well as how big the development teams using it are, and how many projects are running in parallel and have dependancies upon one another or shared/common code that needs to be merged with multiple streams of code/projects.
If so, please could you let me know as we are looking to do the same, and would like to know about other peoples experiences/challenges/decisions etc.
Any help would be greatly appreciated.
Thanks,
Hayley
I migrated several projects so far.
From my experience the best way is to migrate the LATEST version of main and all important branches leaving all history in ClearCase.
Of course after migration main and release migrated branches in ClearCase should be locked to prevent further development.
Best regards
that's a reasonable approach - but what about the developers?
Subversion has a very different use case than ClearCase. How did you address training providing the common source code management usage that developers had come to expect?
Bob
SVN, especially on windows with TortoiseSVN, is so easy to learn that we didn't have a problem with that... I provided couple training slides and after two 1h sessions team was educated enough to be able to switch to SVN. Now they are huge advocates of SVN and they provide trainings to newbies among the team without me.
You're right Bob that SVN is different and you need some time to get accustomed to it but in my company I always hear a sigh of relief from member of teams which got rid of CC and moved to SVN :D
Of course there is many other things you need to consider when moving to SVN:
- SCM process and policy (for example: on CC they had to create defect branches for each change, on svn they commit directly to trunk)
- on CC you have triggers, on SVN you need to create appropriate hooks
- if you have some integration with defect tracking tool on ClearCase (like ClearQuest or Jira), you need to have the same in SVN etc.
Piotus wrote: "in my company I always hear a sigh of relief from member of teams which got rid of CC and moved to SVN."
And what/whom in/about CC would you/they blame?
There are roughly (too roughly!) three layers:
1. base ClearCase
2. UCM (did they/you use it?
3. local administrators (you?)
My own experience says that it is very seldom base ClearCase which is to blame.
Or if it to blame, it is for being misused. First of all, by UCM.
Marc
I am glad that you are enthusiastic and I don't doubt your experience. But I am going to push back on you a little.
ClearCase branching is a lot more powerful and functional than Subversion. Variant management with copy branches in general is different than delta branches (the latter make it much easier to know what files have changed).
Supporting multiple variants is essential for Agile CM (e.g. showing customer requests in beta). You also need to deal with the limitations and issues with merging in Subversion that are much easier and clearer in ClearCase.
My point is - let's be specific about how we deal with the real technical issues that you need to confront when moving from one tool to another. An experienced ClearCase user who understands how to use the product is going to find merging in Subversion to be a bit different. Did you address those challenges and - if so - how?
BTW - I had similar issues when moving from ClearCase/ClearQuest to Rational Team Concert back when the process template was not as mature as the ClearQuest integration with ClearCase.
Bob
"I am glad that you are enthusiastic and I don't doubt your experience. But I am going to push back on you a little."
No problem :D
"ClearCase branching is a lot more powerful and functional than Subversion. Variant management with copy branches in general is different than delta branches (the latter make it much easier to know what files have changed)."
yes, you're right, however in many cases dev team doesn;t need so sophisticated branching strategy with huge version tree and dozens of branch.
Each branch costs so I rather prefer to have them as little as possible.
You can easy check what files changed in SVN too using svn log which is much faster than cleartool find command.
"You also need to deal with the limitations and issues with merging in Subversion that are much easier and clearer in ClearCase."
Less branches you have less merges you need to perform :D I agree that merging (especially tracking merges) in SVN is still a hassle but keeping reasonable numbers of branches makes developer's life easier. So if you want to keep all your changes on separately branches do not choose SVN since it's not so convenient to track merges as in CC.
"An experienced ClearCase user who understands how to use the product is going to find merging in Subversion to be a bit different. Did you address those challenges and - if so - how?"
Yep, I did... First what I showed to them was that they don't need to create branch for each bug, so they don't need to merge so often. Then I explained to them that from version 1.5 SVN has tracking merges feature (each merge is saved into SVN property- svn:mergeinfo). I admit it's not as convenient as ClearCase graphical version tree but I bet after some time of working with SVN you forget about version tree.
In general I'm CM for 6 teams, 3 of them using ClearCase (under unix and windows by means of Remote Client) and 3 are on SVN. Personally I love CC under unix and hate it under Windows (cause of CC Remote Client). I plan to move to SVN world another windows project so it will be 4:3 to SVN ;)
I'm not saying that SVN is the best SCM tool in the world. It depends on many things... But I don;t want to argue here which tool is better. Question was about migration from CC to SVN so it seems that it's decided here which tool is more convenient for your team, right? :D
Best regards
Piotr
Hi everyone,
we can certainly have discussions on whether or not moving from one tool to another is a good/bad idea. In this case, we have assumed that the decision has already been made to move from ClearCase to Subversion. Now the question is only "what are the technical and process issues involved with making that a successful move". I am trying to draw out that this effort involves teaching developers a very different way of working (not saying that is good or bad).
But training is always essential and part of that is defining the use case.
so from your experience what were those issues? Clearly merging has got to be one of them.
As Marc noted if the users were using UCM then we may have some other issues. Jack Repenning was helping us to understand rebasing in Subversion the other day. I am completely tools & process agnostic - but I am not drinking any coo-lade and I want a clear technical process to manage a conversion if that is what the user has chosen.
Bob
Marc,
[quote]And what/whom in/about CC would you/they blame?[/quote]
Main pain in the ass was speed/slowness of updates on ClearCase and Remote Client which is used in my company. Updates takes years and when you break it and want to checkout something you usually cannot cause of some java exception shows up. So you refresh, restore and update your view but it takes years too and it doesn't help often. At the end your view is corrupted and you need to create a new one which takes time and has nothing to do with productivity, right?
[quote]UCM (did they/you use it?)[/quote] Never used it, I know its philosophy but never had opportunity to try.
We use base clearcase on unix and windows. And while there is no complains about CC on Unix, people hates CC in Windows world cause of reasons mentioned above.
Best regards
Piotr
Bob,
[quote]so from your experience what were those issues?[/quote]
As for developer's training:
The main issue was to explain guys:
- that on SVN there is no views and config spec :D
- That it doesn;t make sense to put only one file on the branch when you can put the whole code on branch in 3 second.
- that in SVN you checkout whole repository (trunk or release branch) not each file or directory.
- That when you merge you specify only from where you want to merge since destination is your workspace.
As a part of the training I created SVN test repository and they could play with SVN a little bit asking question in case of any doubts. I think it was very didactic.
As for technical and process:
- hooks have to be prepared (instead of CC triggers)
- SCM strategy has to be changed (it;s not really true, cause our clearcase approach (each change on branch and then merge to main/release branch) is possible
- integration with CQ had to be created from the scratch
- scm tool for auditing before builds had to be created
I'm not sure if you are asking about those type of issues or I completely didn't get your question.
Thanks guys for all your comments.
How large are the projects that are using SVN, and how do you manage parallel releases and parallel changes to the same code set?
We currently do lots of 'inter' project delieveries using CC UCM which is a fairly easy process. We have another large programme of work coming up and we invisage having to do lots of the same; so we need to know how Subversion copes with this, and how much 'admin' is required in these type of scenarios.
Thanks,
Hayley
Harley,
Since I do not have experience with CC UCM maybe I shouldn;t answer at all but:
- largest of my SVN project has 134 978 files and 105 380 directories (1 GB of disk space)
As for parallel releases - each release has it's own release branch. Found bug needs to be added to each branch if particular release is affected.
in other words solution fixed in one branch is merged to all affected branches.
As for parallel changes - each developer creates its own workspace and when fix is ready he/she commits its change to trunk(or release branch). If changes made by one dev A coincide with changes committed ealier by dev B, dev A needs to update its workspace before commit and integrate its change with changes made by others. So commit as often as possible so you won;t need to integrate :D
Usually no admin work is required. everything is done by development team...
Piotr
Thanks Piotr.
So say if you had three releases R1, R2, R3 all were being developed in parallel and all changes from R1 must be included in R2 and R3, and R1 must be deployed before R2, and then R3. So changes need to be regulary merged with R2 and R3, how would this be done? Is it done on a 'per file' basis or would it be the entire branch copied onto the R2 branch and then the R3 branch?
How are bug fixes managed too? Would you have a sub branch from the main branch which devs would take a copy of and then the changes would be pushed back up to the R1 branch and then onto the R2 and R3 branches?
Would you then also have a main line branch so all projects are merged onto here once they have been deployed into Production and then any new projects would be seeded from the production version of all projects if that code is required?
Also, how large is the development team? And how often are releases made?
Thanks.
Hayley
Hayley
No, I'm saying that if "change" committed to R1 affects other releases then it should be included to R2 and R3. if "change" is specific for R1 it doesn't make sense to include it to R2 and R3. Each releases are on separately branch so they can live their own live and you don;t need to deploy R1 before R2 or R3.
Bugs are kept in tool like CQ or Jira. When tester found bug let's call it B1 dev needs to fix it for all releases which are affected. So it can go to branch tied to R1 only or to all three branches.
In my teams we are using following approach:
- main (new features, bugs etc) development is done on trunk (equivalent of main in CC)
- when release is coming release branch is created from trunk
- on release branch only bugs are fixed (no new feature usually)
- all bugs fixed on release branch need to be merged to trunk
- next release - new branch is created from trunk
- if client wants small change in old release - it's done on prior release branch however we are trying to deliver new releases from new branches created from trunk than to maintain old release branches :)
As for the large of dev teams - the smallest one counts about 10 developers, the largest about 50, maybe more :D
Piotus wrote: "Main pain in the ass was speed/slowness of updates on ClearCase and Remote Client which is used in my company."
OK. You see, neither snapshot views not remote clients are part of base ClearCase, in the original sense.
These were added later, as part of what was already the UCM development strategy...
At that time, Rational stopped investing in clearmake and MultiSite, thinking it was not worth its while to push the .JAVAC support in clearmake, and to flesh support for building jars, wars, deployment, etc.
They invested instead in Windows GUIs, and web interfaces.
Marc
MarcGirod, "OK. You see, neither snapshot views not remote clients are part of base ClearCase, in the original sense."
And maybe that's why my all unix C++ teams doesn't want to hear about any other tool than CC, they are happy with dynamic views and pure cleartool commands :D
CCRC is a terrible invention, somebody should be whipped for that./ ;)
CMCrossroads is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.
Hi Hayley,
we are in the process of migrating from ClearCase to Subversion. I see you went thru the same process and I'd appreciate any information/documents on how to do it. My email is [email protected]
Thank you in advance for your help.
Mohamed