Running ClearCase synchronizer, why is synchronizedFilesAfterSync.txt empty?
We have trying to set up synchronizing some ClearCase VOBs with RTC,and we also have set up some importing of VOBs with History (of 1 label).
The initial sync run worked well, but creating elements after that appears impossible,
either from RTC or from ClearCase. Now the first thing I'd check is, what files did RTC import?
This is the supposed directory structure:
\di_dummy1\
.... test1\
.... .... test1.txt
This is the synchronizedFilesBeforeSync.txt of the first job:
Jazz:And this is the synchronizedFilesBeforeSync.txt, of every other job on this stream:
(ohne)
ClearCase:
(ohne)
Jazz:So the component has been created by synchronizer, and that's about it.
di_dummy1
ClearCase:
di_dummy1
Shouldn't the synchronizedFiles logfiles show full content of the component?
Do I have to look for special properties of CC views, RTC streams or components to make this work?
BTW I am running an RTC 4.0.2 server with a 4.0.1 Synchronizer. Will re-try with 4.0.3 software, if that should help.
Accepted answer
If you can't find them in the RTC stream, I'd suspect your label is not picked up by the synchronizer as expected. Pls check the synchronization build log file to see if the label is imported and also see if your label type has the attribute that you specified in the root selection panel.
Comments
You are absolutely right. I set up another synchronized branch, and as I selected only single files within the component, those showed up in synchronizedFilesAfterSync.txt.
This feature seems useful to trim down our code base during import.
But the selection could only applies to labels that are not yet imported, right?
Do you think it is useful to change the root selection, once the flow between clearcase and rtc is established?
As for the import, the flow was stuck in the CLONE workspace, for some merge conflict had happened, and proper resolution was unclear. This is solved now.
We still have issues creating element from the RTC side, because cleartool mkelem returns error codes, probably by cc triggers. That's a different story in its own right.
> Do you think it is useful to change the root selection, once the flow between clearcase and rtc is established?
Would you elaborate more about it?
Yes, changing the root selection only applies to future synchronization requests, and has no effect on the results of previous synchronization requests that were invoked before the root selection was modified.
The main use case for changing the root selection would be in 2-way synchronization mode, first selecting a few files and directories to synchronize (to quickly verify everything is set up correctly), and then adding the rest once things seem to be working. Note that once you have added a sync root that is a parent of an existing sync root, you can remove those child sync roots ... they are now redundant (but do no harm). Note that this technique is not useful for history synchronization, since the earlier baselines will just have a subset in them (I assume that is why you asked whether changing the sync root list affects previous sync requests). So to verify that things are set up properly, do your small-scale testing with a 2-way sync stream, and then once things are running properly, set up a history synch stream, but only select the first couple of baselines/labels to import. If those import fine, then put the attributes on the rest, and request another sync on that history sync stream.
1 vote