It's all about the answers!

Ask a question

Why does requesting build delete files which are not part of stream


Karthik Krishnan (859389127) | asked Sep 11 '12, 6:59 a.m.
edited Sep 11 '12, 9:01 a.m.
I have a "Command line - Jazz build engine" whose main task is to get the contents from the stream on to a folder, which contains files and folders which are not part of Stream. (they cannot be part of any stream)
  
In the build definition I have unchecked "Delete directory before loading"

What happens is that whenever a build is requested, the build deletes all the files which are not part of Stream.

My expectation was that the build will update the workspace without deleting the existing contents.

Is this the expected behavior of the build ?\

we are using RTC 4.0


3 answers



permanent link
Nick Edgar (6.5k611) | answered Sep 18 '12, 2:38 p.m.
JAZZ DEVELOPER
Yes, this is expected behaviour -- it tries to bring the load directory into sync with what's in the build workspace being loaded.  If you want it to leave certain files alone (e.g. generated .o files or something), then you should add these to the ignore list (.jazzignore file).



Comments
Jeff Foege commented Sep 18 '12, 5:55 p.m. | edited Sep 19 '12, 9:34 a.m.

Nick,
   Except (correct me if I'm wrong) I believe the ignore feature won't prevent the files that RTC doesn't control from being deleted. This is one of the really big pain points to me as well. I have a folder where a component is loaded which also contains other folders and those other folders need to remain/be ignored at all operations.

For example, Microsoft's Embedded platform builds in c:\winceXXX, so the component needs to be loaded in this folder. The only problem is we don't want to check in all the files in the \WinceXXX folder because it could total out to be around 40gb even without our source code. We don't unload the workspace thats loaded into Wince in fear it will blow away installed files. If something happens to the Wince folder it would take a better part of a day (maybe a 1.5 days) to reinstall the Embedded platform.

RTC is the only source control system I've worked so far that controls the entire folder structure where the components are loaded. This wouldn't be so bad if the scm system would honor the ignore files for 'Unloading a workspace' and in a build definition of 'Delete Directory before loading".There isn't an easy way to find the ignore file that is ignoring the file you want to update and this doesn't even count for the eclipse ide ignoring files. We had a case where we had a file called rcs that we wanted checked in but the eclipse editor was ignoring RCs file. Which on a Linux system are two different files. It caused a developer all kinds of grief until we figured that out.

Sorry if my comment is a bit winded.


Nick Edgar commented Sep 19 '12, 9:34 a.m.
JAZZ DEVELOPER

No worries, that all makes sense. Is there some top-level directory structure under c:\winceXXX that needs to be protected, or are the files you load mixed in to the existing directory structure? I'm not actually sure how the ignore mechanism treats folders, but I can check with someone from the SCM team, and/or try to model your situation.


Jeff Foege commented Sep 19 '12, 6:14 p.m. | edited Sep 20 '12, 10:19 a.m.

You don't have to check with the SCM team. I fairly certain there are some work items already created to address some of my issues. I must have not bookmarked the particular WI.

Yes there are folders at c:\winceXX that need to be protected.
c;\wince\public (28.4 gb) - Unless we need to change something here, I'm not checking this into RTC.
c:\wince\Platform (292mb) (We have modified some folders here, we only checked in the platforms we changed)
c:\wince\others (515 mb)
c:\wince\Source1 (2.32 gb) - This is our source folder

The jazz folders at the same level. We have a couple other source folders but those aren't very big at all. So out of fear of screwing up those folders I have the workspace disconnect instead of delete. Then I go there and delete the folders that I know of. Luckily we don't change out this workspace very much.

Frankly, there is a level of complexity where you don't need it. If RTC didn't own the workspace then you wouldn't need ignore files and then it would only concert itself with the files that were added in manually. RTC tries to be nice and add in files for you but the side effect is deleting of files it doesn't own.


Heather Fraser-Dube commented Sep 20 '12, 2:59 p.m. | edited Sep 20 '12, 2:59 p.m.
JAZZ DEVELOPER

The root file/folder/symbolic link that is loaded from an SCM repository workspace are are what we consider a "share". if the share is a folder, everything in it and below is considered under SCM control and it is intended to map 1 to 1 with the contents in the repository unless specifically ignored (as Nick explained).  Sibling file/folder/link that are in the same directory as the share are not considered under SCM control and should not be deleted by SCM during an load/unload.

As well a share does not need to be loaded directly under the sandbox. There can be a path to it not under source control that leads to the share.  I am not exactly sure what you are loading where that is causing difficulties. An example may help.

If c:\wince is the sandbox, then loading a folder Source1 from the repository workspace should have no effect on the c:wince\others c:wince\public since these are siblings that are unshared in the sandbox.

I am guessing here, but suspect the difficulties you have are with the c:\wince\Platform folder where there are somethings under source control and somethings not. If in your repository component you have a folder structure "Platform\abc\ourSource\" and you on disk have a folder "Platform\def\someOtherSrc" and you want "abc" & "def" to co-exist, you do not want to load the folder Platform from your repository workspace. Instead you want to load "Platform\abc" and you want it to be loaded in sandbox c:\wince under the folder "Platform". The folder "Platform" in the C:\wince directory is not under source control. "abc" is the share and it will co-exist with other items in the same directory like "def".

With 4.0, we have updated the articles to describe more of the options that you have when loading. If I understand the problem correctly, I think the case you are interested in is described in the article on loading. https://jazz.net/library/article/1016#Loading_into_a_specific_folder_structure


permanent link
Jeff Foege (45256460) | answered Nov 09 '12, 5:26 p.m.
Thanks Heather for the info. I'm finally had enough breathing room to circle back around and try this. I was following the article's link but RTC barfed. When I 'load as' all the individual folders and then go back to preferences to create a load rule, RTC throws an error. The only details is "An error occurred" - "java.lang.NullPointerException".

The only problem I see is that the load rule isn't working on files. I also suspect the error above came cause I also did a 'load as...' on some files. The files in question would be located right under c:\winceXX\Platform\.project and .jazzignore.

So unless I'm doing something wrong then the load rules won't work for us cause the rules only appear to work on a folder level not a file level as well. If however files would work in the load rules then this would work for us.

Comments
Heather Fraser-Dube commented Nov 12 '12, 9:02 a.m.
JAZZ DEVELOPER

Load rules work on the file level as well. I suspect the NPE encountered is work item 213788 which has been fixed in 4.0.0.1. If you are running a client more recent than that, can you raise a work item with the details.

The article was https://jazz.net/library/article/1016 - Loading Content from a Jazz Source Control Repository in Rational Team Concert 4.0.


permanent link
David Olsen (5237) | answered Nov 12 '12, 1:08 a.m.
JAZZ DEVELOPER
Have the build load your workspace to a location that is not underneath C:\winceXXX.  Then have your build script copy the necessary source code to the correct place within C:\winceXXX.  The build script can be as smart as it needs to be about what to copy and what to clean up.

Comments
Karthik Krishnan commented Nov 15 '12, 10:19 a.m.

We are currently using Loadrules + copy 

Build copies to different location and then use scripts in build to copy to different location

We still have lots of issues with this approach but this works 

Your answer


Register or to post your answer.