[closed] ClearCase Synchronizer deletes branch
Hey there,
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
showing 5 of 7
show 2 more comments
|
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
I wonder if those files whose branch has been removed has been checked out once by the synchronizer, but eventually the checkout was undone by the synchronizer because it figured the content is identical between RTC and ClearCase.
Is there the unco trigger configured so the empty branch is automatically removed? Simon Eickel selected this answer as the correct answer
Comments Hi Masabumi,
1
Geoffrey Clemm
commented Apr 18 '13, 1:15 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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.
Hi Masabumi,
Geoffrey Clemm
commented Apr 18 '13, 9:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
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:
|
Comments
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.
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:
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?
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:
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)
Hi Masabumi,
I'm using CC synchronizer version 4.0 (4.0.0.RTC-I20120612-0919-r40).
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.