preventing a file from merging
In ClearCase, we automated stream merging using the cleartool CLI from perl. For files we don't want to merge, we create evil twins in the target stream which prevents the element from merging (cleartool spits out visibility warnings but the merge goes through).
I'm trying to do the same thing in RTC using the SCM CLI. I'd rather not use the same approach (evil twins) to prevent merging and was hoping there is another approach to prevent merging of certain files. I'm considering generating a .jazzignore file during the merge and removing it afterward. Seem reasonable? Is there a better approach? |
4 answers
eanderso wrote:
By "Preventing a Merge" I mean, for certain files, we never If one of the files that isn't supposed to flow is in the same change set as a file that is supposed to flow, then you are out of luck. You have to flow the entire change set or none of it. There is no way to get most of the changes in that change set while excluding the change to the one "don't-flow" file. I'd take a step back and rethink the problem. Is there a way to organize things so that people won't try to flow changes to those files, or so that flowing changes to those files won't cause any problems. Could the release-specific files be put in separate directories with release-specific names? Flowing changes from FooBar 1.0 to FooBar 2.0 wouldn't cause any harm because the files in the "release-1.0" directory wouldn't conflict with the files in the "release-2.0" directory, and the contents of the "release-1.0" directory would just be ignored by the 2.0 build. Could the release-specific files be put in a separate SCM component? Change sets are specific to a component, so it wouldn't be possible for a file that shouldn't flow to be in the same change set as a file that should flow. And it shouldn't be hard to set up your flow targets so that this release-specific component is left out when flowing changes from FooBar 1.0 to FooBar 2.0. I don't know that either of these approaches will work for you. But those are the types of approaches I think you should look into. Comments
Virginia Brown
commented Dec 07 '12, 5:22 p.m.
18 months later this is still an interesting problem. Has anyone made progress on coming up with a jazzignore-like solution that could be used for automated merges? Thinking particularly of Erik's case of propogating R2 changes to R3 etc |
Geoffrey Clemm (30.1k●3●30●35)
| answered May 28 '10, 6:32 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
When you say "prevent the merge", do you want the result to be to keep
the existing version, or to select the incoming version? Normal RTC behavior gives the user the choice of: - try a merge in the editor - select the existing version - select the incoming version. So for "non-mergeable" files, you would select choice 2 or 3. Doesn't this give you all the choices that you need? Cheers, Geoff On 5/27/2010 12:23 PM, eanderso wrote: In ClearCase, we automated stream merging using the cleartool CLI from |
By "Preventing a Merge" I mean, for certain files, we never want the changes to flow between streams. For example, say we have streams for FooBar 1.0 and FooBar 2.0. Both streams contain some file's that are release specific (1.0 vs 2.0) and we don't want them to flow from FooBar 1.0 to Foobar 2.0.
Re. normal behavior, we only get those options if there is a conflict. If there is not a conflict, the changes flow to the target stream. I can force a conflict by creating an evil twin but I was trying to avoid using them for this purpose but it seems like the only approach so far (using jazzignore didn't pan out). |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.