It's all about the answers!

Ask a question

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

Sean Babineau (38825) | asked Sep 19 '12, 10:40 a.m.
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? 


Accepted answer

permanent link
Daniel Toczala (88211514) | answered Sep 19 '12, 12:27 p.m.
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

Your answer

Register or to post your answer.