On 3/12/06, Simon Kitching <[EMAIL PROTECTED]> wrote: > On Sun, 2006-03-12 at 11:36 -0800, Henri Yandell wrote: > > On 3/12/06, Niall Pemberton <[EMAIL PROTECTED]> wrote: > > > On 3/12/06, Stephen Colebourne <[EMAIL PROTECTED]> 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/[EMAIL PROTECTED] > 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/[EMAIL > PROTECTED] > > Cheers, > > Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
