[closed] ClearCase Synchronizer deletes branch
I'm back again with a new curious problem with the CC Synchronizer.
We have the following solution:
A team is migrating their project to RTC but has to deliver to ClearCase because the software they are developing is used by other teams which still use ClearCase.
The RTC project has around 15 components which are mapped to 15 different folders (in one same folder) in CC.
The structure in CC is <VOBname>\DO_NOT_USE\<Componentname>.
In the "DO_NOT_USE" folder all data is present yet because the source data (which was migrated to RTC) came from CC. This means we do have the same folder and file structure in CC as in RTC.
I do the following preconditions before creating the synchronization:
Create a branch on each file / folder (element) in CC from the vob root on (ct find <source> -exec "ct mkbranch ..."") and do an undo checkout on each element that only a <branch>\0 version resides for each element.
After this is done (and the subvob component attribute is set and so on) I start the synchronization process.
I do have one synchronization stream which shall synch all of those components to CC.
At the moment I have the effect that for around 10 components this synchronization worked successfully. But for some components I'm facing the effect that the synchronizer seems to delete the branch on the elements. This looks for me as he thinks in RTC those elements are not present and so he doesn't need the branch in CC.
To give you an impression on it, some screenshots:
before synchronization:
After synchronization:
But for some elements it's working correctly:
Then I took a look inside the RTC component - maybe those files are not present in RTC but they are there:
What did I tried to repair this?
I removed the branch on those elements (rmbranch) and deleted the clones inside the RTC database (ccc clones ...) After this I created the branch again and restarted synchronization ...
Same result.
Anybody any ideas?
Greetings,
Simon
The question has been closed for the following reason: "The question is answered, right answer was accepted" by eickel Sep 16 '13, 1:12 a.m.
Accepted answer
Is there the unco trigger configured so the empty branch is automatically removed?
Comments
Hi Masabumi,
other versions are left with zero branch, but you are right, there is a trigger deleting empty branches. And yes, versions of RTC and ClearCase are identical. But why should the Synchronizer checkout the ClearCase version before checking if it's identical?
I will delete the trigger settings and try it again.
For individual files being brought over, the synchronizer assumes content is usually different, and therefore lets the ClearCase checkin command detect identical content. I.e., it just checks out the file, copies over the new content, and then perform a checkin without a -identical flag. ClearCase will complain if the content is identical, in which case we uncheckout the file. This allows us to skip the content compare for the usual case when the content is different, at the cost of an uncheckout when the content happens to be the same. But then that uncheckout will fire off your uncheckout trigger. Note: The synchronizer sets an environment variable CONNECTOR_SYNC for the trigger environment, so if you modify your uncheckout trigger to be a no-op if CONNECTOR_SYNC is set, you should be OK.
1 vote
Hi Masabumi,
thanks for this tipp. Yes the trigger (running just on a undocheckout) does the rmbranch.
After deleting this trigger everything is fine.
Problem is that the trigger is needed on this VOB ...
Simon: See my comment immediately before yours, about the CONNECTOR_SYNC environment variable. For details, see the "Writing Rational ClearCase triggers for synchronization" in the on-line help:
https://pic.dhe.ibm.com/infocenter/clmhelp/v4r0m2/index.jsp?topic=%2Fcom.ibm.team.connector.scm.cc.doc%2Ftopics%2Ft_sync_cc_triggers.html
Comments
Karl Weinert
JAZZ DEVELOPER Apr 17 '13, 1:04 p.m.So you are saying that the import from RTC somehow does an rmbranch operation?
What does cleartool lshistory -minor <element name> show?
It isn't just changing the config spec is it?
And just a side note you can use cleartool mkbranch -nco (no check out) to create the zero version of a branch. That way you won't have to uncheck them out afterwards.
Simon Eickel
Apr 17 '13, 2:30 p.m.Hi Karl, thanks for the mkbranch -nco statement ;) this I didn't noticed ;) It's much easier now to recreate this error ^^
To your other question:
In the version tree the branch is gone ... so I thought there was a "rmbranch" operation. Now I recreated this situation and ... yes ... there is a destroy branch:
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Apr 19 '13, 1:01 a.m.Hi Simon, I seem to have inadvertently deleted your answer to my question as to why you are creating branches with just a single branch/0 version. In particular, your response was:
I do the step with zero version on the branch because when I run the synchronizer without creating version zero it fails throwing this error:
build.log:
StackTrace:
If it would be convenient, could you re-post the error you got?
Simon Eickel
Apr 19 '13, 2:00 a.m.Hi Geoff,
and I thought "whooho ... my posts was not liked so it was deleted" :)
For sure I can give you the trace again:
build.log:
StackTrace:
Masabumi koinuma
JAZZ DEVELOPER Apr 19 '13, 12:36 p.m.Wow, this looks like a bug. Which version of CC synchronizer is it?
It could be a known issue that has been fixed for upcoming release (4.0.3) because I remember we've fixed several issues in the logic to re-locate files while exporting.
I filed another defect to keep track of it : NullPointerException when exporting from RTC to CC (261680)
Simon Eickel
Apr 22 '13, 1:28 a.m.Hi Masabumi,
I'm using CC synchronizer version 4.0 (4.0.0.RTC-I20120612-0919-r40).
Masabumi koinuma
JAZZ DEVELOPER Apr 22 '13, 8:22 p.m.Thank you, Simon. It seems like the issue would have been fixed along with sync from RTC to CC blocked with: cleartool: Error: Cannot link directory (246277) in the upcoming release. I need to do more research to confirm it, though.