Thanks, Gilles. This worked pretty well. The only issue is that due to the Comparator implementation, when comparing two revisions in which only one has a term with special meaning, the special meaning is essentially ignored and the revision with just numbers is chosen as the latest. I'd like to see the algorithm replace the special meaning terms no matter what the second revision is. Scott
Gilles Scokart <[EMAIL PROTECTED]> wrote: I had to solve a similar problem. I used this into my configuration : the priority over official build --> priority --> I published my automated build using build.XXXX , and the build published by the developpers have the version number dev.XXXXX (I think the XXXX were a timestamp + userID). Gilles 2007/10/30, Scott Goldstein : > > In my environment, I have an ivy file set up to depend on the > latest.integration version of a module. This module is generally > published to a file server repository within a folder denoted by a nightly > build number. Naturally, each night there is a new build with a higher > build number, so the latest version is always taken. > > What I'd like to do, is allow a developer to build the required module > on his/her machine and publish to a local repository. This built version > would then "override" the version on the file server. > > To do this, I've created a local repository definiteion and put it first > in the repository chain. The problem that occurs, is that the build number > of the module on the file server is higher than the number used in the local > repository, so the one on the file server is used instead. > > So, I suppose the ultimate problem here is that the nightly build > numbers on the file server continue to increase. How can I publish to the > local repository such that it always ovverides that of the file server? One > solution, is to have this bulid number be available on the dev machines > through some sort of file populated by the nightly build system. This isn't > ideal. I think ideally, I would want the resolution to take a matching > module in the first repository it finds, rather than looking through all > repositories and comparing "revisions" before it take the latest revision. > > Is this possible? > > If not, anyone have any other ideas? > > Thanks. > > Scott > -- Gilles SCOKART
