Mailing-List: contact ivy-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ivy-user@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of xavier.hanin@gmail.com
 designates 64.233.162.237 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=LnXwyKYngj6avkMp0d7dZMHQVyQc9Ya5yuekO9bfBrV1tWIBbjZ0s23gbCThytfy41pw1i6SgHd9IyjtjkXp63yArxqqIvgYYTegiUsQwshcNLJPzXLdfCSy0UwxkU63YOdEYqPJaD6nJL0Gd0fHXKyzYqLLsiVsTIQAVdidkCU=
Message-ID: <635a05060706070518l69da9c54hb96b6fba875d4a26@mail.gmail.com>
Date: Thu, 7 Jun 2007 14:18:58 +0200
From: "Xavier Hanin" <xavier.hanin@gmail.com>
To: ivy-user@incubator.apache.org
Subject: Re: Relationship between branches, revisions;
 integration, and release.
In-Reply-To: 
 <B408B6F6E3DEB04681E207B528821D494B3707@DUL1WNEXMB05.vcorp.ad.vrsn.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_50180_15795516.1181218738364"
References: <635a05060706070417k6aa3982dl770077172cc3a75c@mail.gmail.com>
	 <B408B6F6E3DEB04681E207B528821D494B3707@DUL1WNEXMB05.vcorp.ad.vrsn.com>

------=_Part_50180_15795516.1181218738364
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 6/7/07, Buck, Robert <rbuck@verisign.com> wrote:
>
> Hi Xavier,
>
> I think this might be a matter of definition; I did not provide you a
> piece of information.
>
> We do NOT assign version numbers to branches, as a rule; we consider it
> bad practice. In theory, the only rules that a branch name must follow
> are:
>
> - unique within a single release vehicle (meaning 'ACME' may be used
> only once for product foo, but may also be used once by product bar)
>
> - subsequent releases have a name that lexicographically sort AFTER the
> former release.
>
> So what we do is, branches are always U.S. town/city names, sequentially
> sorted and assigned. For a particular release vehicle, we establish a
> gapping policy of 10 town names just in case we need to slip in an
> interim release. An example branch name may be:
>
>   BILINGSERVER-ACME
>
> Version numbers, however, are only assigned when a product is released.
> And the only place these numbers are referred to is:
>
> - the IVY release repository
>
> - the installation, users guides, operations guides, documentation
>
> - the images directory where the installer is dropped
>
> ...
>
> So if I depend upon a branch, it would look something like:
>
>     <dependency name="bsgw" rev="latest.integration"
> branch="BILINGSERVER-ACME" conf="default"/>
>
> Since it is only the artifacts in the integration repository that has
> the 'status="integration"' flag set, shouldn't it resolve to:
>
>   $ivyrep/integration/verisign/bsgw/BILINGSERVER-ACME/ivys/ivy.xml
>
> Won't this work? Yes/No?


OK, I better get your situation now. One thing to know about the
latest.integration version constraint is that it matches everything,
including milestone and release. Why that? Because if getting a simple
integration version, a milestone or release (which are usually better tested
:)) is even better. If you want a version constraint matching only versions
in integration status, you will need to provide your own (which is very
easy). But the problem of relying on the status is that the status of a
module can only be known by parsing the module descriptor (the ivy file).
Thus using status dependent version constraints does not perform very well
and is not recommended.

So the answer to your question is that it won't work like that. Indeed when
you ask for latest.integration version of the branch BILINGSERVER-ACME, Ivy
will check the release and integration repository (according to your
settings). In the integration repo, only module on the branch will be found.
Fine. On the release repo, since you have no branch in the pattern, Ivy will
find your module too. If the release module is younger than the integration
one, it will take it. So the easiest solution is to put a branch token in
the release pattern, and give a single branch name for your releases ('main'
or 'HEAD' for instance). Then Ivy won't find any module in the release repo
when looking for a branch which is not 'main'. If you don't like having this
additional directory in your layout, you can take advantage of your version
naming conventions which seems to be different between integration and
release versions: you will need to write a custom VersionMatcher, but this
is easy to do. This version matcher could say that
latest.integrationmatches a release version number only if there is no
branch information.
There are also other solutions which involve settings switching depending on
context, but this works only if you fully separate your dependency
resolution for release and integration.

HTH,

Xavier

Bob
>
> > -----Original Message-----
> > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > Sent: Thursday, June 07, 2007 7:17 AM
> > To: ivy-user@incubator.apache.org
> > Subject: Re: Relationship between branches, revisions;
> > integration, and release.
> >
> > On 6/7/07, Buck, Robert <rbuck@verisign.com> wrote:
> > >
> > > Hi Xavier,
> > >
> > > It might be that you simply missed it in all that xml code.
> > But on the
> > > integration side I thought the branch was handled:
> > >
> > > <artifact
> > >
> > pattern="http://localhost:20080/ivyrep/integration/[organisation]/[mod
> > > ul e]/[branch]/[type]s/[artifact]-[revision].[ext]"/>
> > >
> > > Or am I missing something?
> >
> >
> > I saw the branch on the integration side. What I was talking
> > about is the release side. If you configure Ivy like you
> > suggest, when you ask for a latest version, Ivy will try to
> > find it both in your release repo and integration one. So Ivy
> > may take a version in the release repo believing it's more
> > recent than the other one in the integration repo, even if
> > you asked for a particular branch, because your release repo
> > do not have a branch token in the pattern. This may or may
> > not be an issue depending on your release and dependencies policy.
> >
> > Xavier
> >
> > Bob
> > >
> > > > -----Original Message-----
> > > > From: Xavier Hanin [mailto:xavier.hanin@gmail.com]
> > > > Sent: Thursday, June 07, 2007 3:22 AM
> > > > To: ivy-user@incubator.apache.org
> > > > Subject: Re: Relationship between branches, revisions;
> > integration,
> > > > and release.
> > > >
> > > > On 6/6/07, Buck, Robert <rbuck@verisign.com> wrote:
> > > > >
> > > > > In an earlier thread on "best repository layout" a
> > > > suggestion was made
> > > > > by Xavier where I should consider how to handle branches,
> > > > and also how
> > > > > to handle integation and releases.
> > > > >
> > > > > From what I can determine this comes down to two settings:
> > > > >
> > > > > A. the status fields in the ivys files in the repository B. the
> > > > > [branch] vs [release] attributes in the patterns
> > > > >
> > > > > Would then it make sense to do something like the following?
> > > > > (wondering if I pulled the concepts together correctly).
> > > > >
> > > > > <?xml version="1.0"?>
> > > > > <ivyconf>
> > > > >   <resolvers>
> > > > >     <url name="public-resolver">
> > > > >       <ivy
> > > > >
> > > >
> > pattern="http://localhost:20080/ivyrep/release/[organisation]/[modul
> > > > e]
> > > > > /[
> > > > > revision]/ivys/ivy-[revision].xml"/>
> > > > >       <artifact
> > > > >
> > > >
> > pattern="http://localhost:20080/ivyrep/release/[organisation]/[modul
> > > > e]
> > > > > /[
> > > > > revision]/[type]s/[artifact].[ext]"/>
> > > > >       <artifact
> > > > >
> > > >
> > pattern="http://localhost:20080/ivyrep/release/[organisation]/[modul
> > > > e]
> > > > > /[ revision]/[type]s/[artifact]-[revision].[ext]"/>
> > > > >       <artifact
> > > > >
> > > >
> > pattern="http://localhost:20080/ivyrep/integration/[organisation]/[m
> > > > od
> > > > > ul e]/[branch]/[type]s/[artifact].[ext]"/>
> > > > >       <artifact
> > > > >
> > > >
> > pattern="http://localhost:20080/ivyrep/integration/[organisation]/[m
> > > > od
> > > > > ul e]/[branch]/[type]s/[artifact]-[revision].[ext]"/>
> > > > >     </url>
> > > > >   </resolvers>
> > > > > </ivyconf>
> > > > >
> > > > > Here, nothing is released unless it has a number,
> > otherwise it is
> > > > > always on a branch, even if the branch were "mainline". And, we
> > > > > partition the ivyrep between release and integration, which
> > > > may make
> > > > > it easier to manage.
> > > > >
> > > > > Thoughts?
> > > >
> > > >
> > > > This sounds like a good layout according to your
> > development rules.
> > > > If you never release things on a branch it's fine.
> > > > There is one thing you should take into account though:
> > the way you
> > > > declare your dependencies and how they evolve over time. When you
> > > > depend on a branch in integration, you will have something like
> > > > this:
> > > > <dependency org="acme" name="foo" branch="bar"
> > > > rev="latest.integration"/>
> > > >
> > > > The problem you might have is that if you have release which is
> > > > yougest than the integration version on branch 'bar', Ivy
> > will pick
> > > > it up, because you have no branch information in your release
> > > > repository. Thus having a [branch] token in your release layout
> > > > could make sense, even if the value is always 'mainline' for
> > > > instance. This would let Ivy know that release can only
> > be used when
> > > > the branch is 'mainline'.
> > > >
> > > > Xavier
> > > >
> > > > Thanks in advance,
> > > > >
> > > > > Bob
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Xavier Hanin - Independent Java Consultant Manage your
> > dependencies
> > > > with Ivy!
> > > > http://incubator.apache.org/ivy/
> > > >
> > >
> >
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant Manage your
> > dependencies with Ivy!
> > http://incubator.apache.org/ivy/
> >
>


-- 
Xavier Hanin - Independent Java Consultant
Manage your dependencies with Ivy!
http://incubator.apache.org/ivy/

------=_Part_50180_15795516.1181218738364--