commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@gmail.com>
Subject Re: [PROPOSAL][all] Break dependency on commons-build
Date Sun, 12 Mar 2006 20:55:38 GMT
On 3/12/06, Simon Kitching <skitching@apache.org> wrote:
> On Sun, 2006-03-12 at 11:36 -0800, Henri Yandell wrote:
> > On 3/12/06, Niall Pemberton <niall.pemberton@gmail.com> wrote:
> > > On 3/12/06, Stephen Colebourne <scolebourne@btopenworld.com> wrote:
> > > > IIRC, we've been advised against overuse of svn:externals before. The
> > > > mechanism I've described is simple enough - just use the Internet for
> > > > what it was supposed to be used for. And no duplicated files at all.
> > >
> > > I agree that lots of svn:externals for each component would be a PITA
> > > - but if we put everything in a single directory in commons-build then
> > > that would be one per component, which once added shouldn't need to
> > > ever change. One svn:external per component isn't overuse IMO and is
> > > exactly what its designed for.
> > >
> > > +1 to Sandy's suggestion from me.
> >
> > Biggest problem with svn externals is that they're not hooked into svn
> > moves. So have to be kept up to date when we move a component from one
> > place to another, or just change the svn url structure.
>
> Fair point.
>
> To give an example, a path "svn.apache.org/repos/asf/foo/bar" will break
> if foo is renamed to baz.
>
> Externals can take a revision#, eg
>  "bar -r1000 http://svn.apache.org/repos/asf/foo/bar"
> however this still doesn't handle renames, as this syntax *first* causes
> svn to look for the path in the current revision of the repo, then track
> backwards on that object to find revision 1000.
>
> This should be fixable, though, by using "peg" syntax in the externals
> url. According to the svn book,
>  http://svn.apache.org/repos/asf/foo/bar@1000
> should look into version 1000 of the repository to find the specified
> directory. This would make the externals URL safe against renames.

>From what I can see this means we would be tieing the svn:external to
a specified revision - which means if something in commons-build
changed then it wouldn't get picked up without re-doing the
svn:external - have  got that right?

If that is the case, looks like a nightmare to me - we'll be forever
updating externals. I think if we created something like a
"shared-build" directory in commons-build then we could just link
svn:externals to that - anything that gets dropped into it, gets
picked up. Maybe we should do it through a versioned branch so that if
someone wants to change something that would break older versions
working, then they create a new versioned branch.

I think the "things getting renamed" if we used a directory wouldn't
be a big issue.

Niall


> http://svnbook.red-bean.com/nightly/en/svn.advanced.pegrevs.html
>
> Unfortunately I can't get "peg revisions" to work for me using svn 1.1.4
> on debian, though the documentation does say the functionality was added
> in release 1.1.
>
> Can anyone else get peg revisions to work? eg:
>   svn cat
> http://svn.apache.org/repos/asf/jakarta/commons/proper/logging/trunk/project.xml@377182
>
> Cheers,
>
> Simon

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message