I had to solve a similar problem. I used this into my configuration :
<latest-strategies>
<latest-revision name="local-revision">
<specialMeaning name="build" value="100"/> <!-- Build received
the priority over official build -->
<specialMeaning name="dev" value="101"/> <!-- Dev received the
priority -->
</latest-revision>
</latest-strategies>
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 <[EMAIL PROTECTED]>:
>
> 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
