Good point, Ruben. But i know a lot of people want to split up their build into several projects for some reasons... We also did this at work and it was almost impossible to force the correct build order so that it always leads to a usable state... In our case we had a lot of installers that didn't contain a consistent deployment.
I remember a discussion about priorities for queues, not only for projects in a queue, and a slightly changed way of locking queues (higher prio always gets the lock first). I think this could solve a lot of problems but i'm not certain if it will allow all possible scenarios. Ideas anyone? regards, Daniel Ruben Willems <[email protected]> wrote: > Hi > > why not just build the solution, iso creating a ccnet project for each > project? > That simplifies things a lot. > > > > with kind regards > Ruben Willems > > On Wed, Jul 1, 2009 at 4:06 AM, Carl Cerecke > <[email protected]>wrote: > > > > > What is the best way to ensure project dependencies in the shape of > > a diamond are built in the correct order? > > > > For example D depends on both B and C, and B and C both depend on A. > > > > Using the advice on > > http://confluence.public.thoughtworks.org/display/CCNET/Integration+Queues > > doesn't work: > > > > If A B C D all share a queue, and priorities are D > C = B > A (so D > > is a higher priority; i.e. a lower priority number), then after A > > builds, B and C will be put on the queue, but after B (say) > > finishes, it forcebuilds D which jumps in front of C. > > > > What would be ideal is to simply specify dependencies between > > <project>s and have ccnet automatically create integration queues > > for sets of disjoint acyclic project-dependency digraphs, including > > automatically handling forcebuilds, to ensure dependencies are > > correctly applied. > > > > Having to handle it manually with priorities seems error-prone and, > > as far as I can tell, not able to handle the diamond dependency > > problem. Feel free to correct me though! > > > > Our project-dependency graph is quite a bit more complicated than a > > simple diamond, so a general approach to the dependency problem > > would be better than a hack for the 4-project diamond special case. > > > > Cheers, > > Carl. > > -- > > Carl Cerecke > > GeoBase Senior Software Engineer – Telogis Research > > www.telogis.com www.telogis.co.nz > > +1 949 625-4115 ext. 208 (USA) +64 3 339 2825 ext. 208 (NZ) > > > > Leading Global Platform for Location Based Services > > OnTrack and GeoBase enable over 350,000 vehicles and mobile devices > > worldwide. > > -- > > This e-mail, and any attachments, is intended only for use by the > > addressee(s) named herein and may contain legally privileged and/or > > confidential information. It is the property of Telogis. If you > > are not the intended recipient of this e-mail, you are hereby > > notified that any dissemination, distribution or copying of this > > e-mail, any attachments thereto, and use of the information > > contained, is strictly prohibited. If you have received this > > e-mail in error, please notify the sender and permanently delete > > the original and any copy there of. > >
