It's all about the answers!

Ask a question

Changesets that have two changes on same file


Mehmet Ali Aydın (6133) | asked Oct 03 '11, 3:46 a.m.
Hello,

We faced with a problem on our build engines and we had to look at the changesets in depth and we detect two changesets that have two changes on same file.

Hope screenshots tells more than words:

Case1:

http://tuanaweb.com/img/addAndDelete.JPG

In fact I can't reproduce this!! First I thougt it can be created with an old version but it's creation date is after our v.3.0.1 update..


Case2:

http://tuanaweb.com/img/deleteAndAdd.JPG

Well this is the screenshot of reproduced case.

I think this must be bug, just think you delete a file with a mistake and than restore it from eclipse. Then you will deliver a change for that file while it is not changed. Also you will see is as two different files in your component history.

Well, if it is something done intentionally, please somebody tell me the process order when accepting this changes. Cause for both changes RTC keeps the file in local workspace.

This problem affects our custom build engine tool which uses RTC-Client-plainJavaLib-3.0.1 and RTC-BuildSystem-Toolkit-Win-3.0.1 libraries. It accepts changesets, loads only accepted files file by file and organizes the local files(Detects old-new paths and changekind for a change and adds, deletes or modifies file) For these two changesets it's behavior is different than RTC. RTC always keep the added - modified file but our tool does not keep the file for all cases. When the same file modified, it can't find the old file in local workspace and produce an error then forces a complete load of the component with final config.

Thanks in advance!

2 answers



permanent link
Geoffrey Clemm (30.1k33035) | answered Oct 03 '11, 11:21 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I believe what happened in case1 is that it actually was the same as
case2, i.e. a file was deleted, and then a new file with that same name
was created. But you (and your scripts) are being confused because when
the Change Explorer encounters this case when the deletion and addition
are in different change sets, it appears to show the deletion before the
addition (even though the changes really occurred in the opposite order).

To determine whether this is what is happening in your case, look at the
history of the component and see if the deletion comes before the
addition. It is likely that is what happened, because you indicate that
the file still exists.

Cheers,
Geoff

On 10/3/2011 4:53 AM, underprotect wrote:
Hello,

We faced with a problem on our build engines and we had to look at the
changesets in depth and we detect two changesets that have two changes
on same file.

Hope screenshots tells more than words:

Case1:

http://tuanaweb.com/img/addAndDelete.JPG

In fact I can't reproduce this!! First I thougt it can be created with
an old version but it's creation date is after our v.3.0.1 update..


Case2:

http://tuanaweb.com/img/deleteAndAdd.JPG

Well this is the screenshot of reproduced case.

I think this must be bug, just think you delete a file with a mistake
and than restore it from eclipse. Then you will deliver a change for
that file while it is not changed. Also you will see is as two
different files in your component history.

Well, if it is something done intentionally, please somebody tell me
the process order when accepting this changes. Cause for both changes
RTC keeps the file in local workspace.

This problem affects our custom build engine tool which uses
RTC-Client-plainJavaLib-3.0.1 and RTC-BuildSystem-Toolkit-Win-3.0.1
libraries. It accepts changesets, loads only accepted files file by
file and organizes the local files(Detects old-new paths and
changekind for a change and adds, deletes or modifies file) For these
two changesets it's behavior is different than RTC. RTC always keep
the added - modified file but our tool does not keep the file for all
cases. When the same file modified, it can't find the old file in
local workspace and produce an error then forces a complete load of
the component with final config.

Thanks in advance!

permanent link
Mehmet Ali Aydın (6133) | answered Oct 05 '11, 5:26 a.m.
Hello Geoff,

First of all I want to update the version info as v.3.0.0 IFix1 for the cases. But the reproduced case was created with v.3.0.1 server and v.3.0.0 IFix1 client as below:

We deleted a file thats already in repository and checked it in.
Then we restore the file and checked it in the same changeset.

The reproduced case did not cause a problem for our application while the original one did. But the view in change explorer was same.

Now we don't have a test environment for v.3.0.0 IFix1 so I can't research the original cases. But I believe the reproduced case is still a problem. You will deliver a change set with two changes (delete & add) while it's nothing or only a modification. Also will see two different history for the file. I plan to open a PMR but first I want to learn if there is a justification?

I also tried add-checkin and delete-checkin but RTC was able to understand it's not a change. Next I will try checkin files from different local workspaces and moving changes between changesets. May be the case is one of these.

Regards,
Mehmet Ali Aydn

I believe what happened in case1 is that it actually was the same as
case2, i.e. a file was deleted, and then a new file with that same name
was created. But you (and your scripts) are being confused because when
the Change Explorer encounters this case when the deletion and addition
are in different change sets, it appears to show the deletion before the
addition (even though the changes really occurred in the opposite order).

To determine whether this is what is happening in your case, look at the
history of the component and see if the deletion comes before the
addition. It is likely that is what happened, because you indicate that
the file still exists.

Cheers,
Geoff

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.