It's all about the answers!

Ask a question

preventing a file from merging


Erik anderson (38315029) | asked May 27 '10, 12:23 p.m.
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



permanent link
David Olsen (5237) | answered May 28 '10, 5:23 p.m.
JAZZ DEVELOPER
eanderso wrote:
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.

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


permanent link
Geoffrey Clemm (30.1k33035) | 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
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?

permanent link
Erik anderson (38315029) | answered May 28 '10, 11:50 a.m.
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).

permanent link
Erik anderson (38315029) | answered Jun 02 '10, 10:14 a.m.
Thanks for the reply

My example was purposely simplified. In reality, we have other reasons for not wanting to merge some files between streams and due to the number of development projects we support (dozens with several dozen builds), it's unrealistic for us to reorganize the source/build (unless it's absolutely the only way). Also, that approach complicates the branching process (we'd have to make new directory's and change the build system to use them)

Note, we understand that to avoid the merge, we will have to create an additional "Change Set" in order to keep the version from the target stream (similar to what happens when resolving a merge conflict).

It doesn't look like we can do it with the SCM tool, so our next step is to try it with the java API.

Comments
Tim Mok commented Dec 10 '12, 11:10 a.m.
JAZZ DEVELOPER

Creating separate change sets for release specific files would help you out in this case. It's going to be much clearer with the change history than creating evil twins. I don't think ignore files will help unless it's to prevent accidentally checking in release specific files. The ignore file won't prevent a change from being accepted because its purpose is to ignore local changes.

This can work in all the clients including the SCM tools. You have to specify which change set you want to use for check-in. The Java API would be the same thing. If you try to check-in without specifying a change set, the check-in operation will try to figure out the best change set to use (the active/current change set takes precedent or another open change set that modified that file).

I think David's answer is the best thing to do in the long run. If it's possible to set up your configuration that way, it would make it much easier. Changes can flow between the releases but the release specific files would be separated. Developers won't accidentally deliver release specific files together with changes that should flow to other releases.

Your answer


Register or to post 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.