Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Best way to enable Source Control to prevent filename collisions during a build?

For a simplified example, let's say that a customer has a build process which must consolidate source files into a single directory. E.g. source files src1/foo.c and src2/bar.c get copied by the build to create out/foo.o and out/bar.o

What would be the best way to enable/customize RTC so that they could enforce and prevent collisions before they get to the build? 

Would this require coding a customized Team Advisor precondition to check a list of registered file names whenever a new source file is added to src1/ or src2/ , to make sure that name doesn't exist in either of the directories? Or is there some better way? 

Thanks!
Sean

0 votes


Accepted answer

Permanent link
You can create preconditions to check for this sort of thing, but that ends up impacting the addition of source files for EVERYONE.  if the process is shared, you are then imposing this restriction on even those projects that do not require it.

I would do one of two things to address this situation:
1) Establish something in my build process that detects these conditions, and then FAILS the build, with an appropriate error message that allows the developer to easily determine which files overlap.
2) If all of the source needs to be in the same directory, then put it all into the same directory in the SCM system.

I understand that option 2 may have some performance impact as well, and may make working with the source difficult to do (as you scroll through the 20,000 filenames looking for the file that you want).  If this is the case, where there are a large number of files to deal with, then option 1 becomes my preferred approach.

From a philosophy perspective, I prefer option 1 anyhow.  If the build process is imposing this restriction, then it should be the build process that detects this condition and has to handle it.  I always cringe whenever we need to make tools (either IBM tools or someone else's tools) conform to bizarre standards or restrictions, due to the the inadequacies or idiosyncrasies of other tools in the development toolchain.  In short, "If tool A is broken, then fix tool A, and don't impact the performance and stability of tool B in order to address these deficiencies".
Sean Babineau selected this answer as the correct answer

2 votes

Your answer

Register or log in 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 562
× 89
× 27

Question asked: Sep 19 '12, 10:40 a.m.

Question was seen: 4,622 times

Last updated: Sep 19 '12, 12:27 p.m.

Confirmation Cancel Confirm