I have a bad fortune of using ClearCase with UCM at work. We try to find a way to get user experience smoother while using it. One of the main problems is that all files are read-only until checked out. This interferes with using IDEs and their refactoring capabilities. Unreserved checkout changes little as it still requires perform check out explicitly. Can Edit-Merge approach be somehow emulated? For example, can ClearCase somehow make unreserved checkout on file modification automatically and not impose read only mode on them?
-
Just in case anyone happens to be using a ClearCase/Java/Eclipse setup, Eclipse does have an official ClearCase plugin (or two) that can automatically check out files that get hit by a refactor operation. – Mike Daniels Jul 02 '10 at 20:42
-
@Mike: true, I have added its (the Eclipse ClearCase plugin) link in my answer. – VonC Jul 02 '10 at 20:48
1 Answers
The way we approach the interaction between:
- refactoring operations
- ClearCase
is to use an IDE with a good ClearCase plugin:
The only way to preserve the history for files is doing the refactoring through an IDE like Eclipse without checkouting the files first: The ClearCase plugin will 'cleartool move
' the files from their old name to their new names and checkout/checkin them, preserving their history.
The other manual way is less ideal:
You isolate that operation in a snapshot view in which, just for this refactoring, we clear up the read-only bit from all the files (so they are all in "hijacked" state).
Once the refactoring is done, we use the result as a source to import in a dynamic view.
clearfimport -mirror
.
You can use a dynamic view as the destination, but the end result is new files with no link to their former filename.
The main idea being: you don't refactor your code every 5 minutes or even every day, so , with the right tool, you could have an acceptable way of mitigating the file-centric nature of ClearCase.
-
Hmm, I often refactor for several times a week. I mean renames and moves. When I develop new feature, I often discover better naming or packaging than initially designed and want to apply them. Thanks for your answer! – Rorick Jul 02 '10 at 21:00
-
@Rorick: I understand. For highly dynamic coding steps like the one you mention... I... I don't checkout/checkin at all. I use a Git repo directly within my ClearCase view ;) http://stackoverflow.com/questions/2342131/how-to-bridge-git-to-clearcase/2342164#2342164. – VonC Jul 02 '10 at 21:05
-
I use local svn repo similarly, but git seems to be more appropriate. I'm going to play with it in next several months. But what troubles me is that as a result history in CC gets more coarser grained that contradict good version control practices. It is not unusual to see check in of very vast code changes in single version in CC. – Rorick Jul 02 '10 at 21:29
-
@Rorick: it is true for repository-wide changes (like refactoring can be), but you can also have more finer-grain history at individual file level. That is just the nature of that particular VCS (http://stackoverflow.com/questions/645008/what-are-the-basic-clearcase-concepts-every-developer-should-know/645771#645771) – VonC Jul 02 '10 at 21:47