It's all about the answers!

Ask a question

Continuous Build error due to folder move

Karthik Krishnan (8825118163) | asked Jan 16 '14, 5:21 a.m.
We have a continuous build on RTC. Only the changes are accepted and build and "Delete directory before 
loading" is unchecked. 

Out stream consists of many components and components are loaded as folders.

This setup works fine until the point when the new changeset contains changes which involves folders/files being moved to different levels ( and sometimes even components in same stream)

At this point, the build throws the following error

[Jazz build engine] Fetching files to fetch destination "D:\b\" ...$3: Status ERROR: code=2 Folders to load overlap other contents null children=[Status ERROR: code=0 /Build.Image overlaps 2 other folder(s) null]
at Source)
Contains : 0 /Build.Image overlaps 2 other folder(s)

In this case the folder "Build.Image" has been moved elsewhere.

Only way we know is to delete the fetch location and restart the build. Since this is a continuous build, how can  this process does not make sense. 

How can we make RTC handle this on changes to filesystem level too? 

Heather Fraser-Dube commented Jan 16 '14, 10:11 a.m.

Are you using load rules for your build? Can you describe where "Build.Image" used to be in relation to the other shares (top level items) that were loaded. Then where it is after the move. Did any shares (top level items loaded) move underneath "Build.Image"?

At this moment, you would need to check off "Delete directory before loading". But I am trying to understand if we can determine what the problem is and handle it better in the build engine.

If you have this error using load rules and after deleting the directory before loading, that would indicate a problem with what you have specified in the load rule.

Karthik Krishnan commented Jan 16 '14, 11:44 a.m.

we are not using load rules for loading build the workspace

This is what happened:
At Time T1

At Time T2 the Folders & it's files had been moved

I see the move history too in the change set

The point is this is a continuous integration build which runs as and when the changeset  comes in to the stream and how can this be handled without deleting the whole load directory?

2 answers

permanent link
Krzysztof Kaźmierczyk (7.4k374103) | answered Jan 16 '14, 9:02 a.m.
Hi Karthik,
We had another user having this issue: Just try recreating new workspace to check whether it helped.

Karthik Krishnan commented Jan 16 '14, 9:12 a.m.

Issue is that we need to do this as and when there is a "Move" of folders /files which is not a wanted behavior for us 

permanent link
Scott Cowan (966310) | answered Jan 16 '14, 10:44 a.m.
Hi Karthik,

It is likely that something else has happened in your workspace, components and folders for this folder collision to happen.  I ran some test builds here using the options you described and didn't have any problems loading source.  As Heather suggested, run a build after checking "Delete directory before loading" to clean up the load directory.  Then you can uncheck it again and your continuous build should be unblocked.


Karthik Krishnan commented Jan 16 '14, 11:45 a.m.

Like I mentioned checking this "Delete directory before loading" & running build works bu the questions is how can this be handled automatically. 

Please see my above comment for example (my usecase)

Scott Cowan commented Jan 16 '14, 11:51 a.m.

Hi Karthik,

Heather guessed what specifically was causing your problem and I am able to reproduce it now in v4.0.1.  It is the move of a component root folder into another folder.  What version are you using?

I've opened this defect, SourceControlUtility.updateFileCopyArea fails if component root was moved to another folder (298101).

Please update the work item with any further comments,

Karthik Krishnan commented Jan 16 '14, 12:13 p.m.

 Thanks Scott.

We use RTC 4.0.2 

Karthik Krishnan commented Jan 17 '14, 9:55 a.m.

same in 4.0.5 too. As suggested I will raise a PMR 

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.