[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: SVN layout



On Thu, Aug 25, 2005 at 04:56:14PM -0300, Otavio Salvador wrote:
> Horms <horms@debian.org> writes:
> 
> > On Thu, Aug 25, 2005 at 11:33:08AM +0200, Bastian Blank wrote:
> >> On Thu, Aug 25, 2005 at 05:54:30PM +0900, Horms wrote:
> >> > > This layout removes the indicator, where changes may be introduced
> >> > > without breaking too much.
> >> > experimental seems like a pretty fair indication.
> >> 
> >> Only if you do regular cleanups of not longer used trees. Otherwise you
> >> remain with
> >> 
> >> sid/bla
> >> experimental/bla
> 
> And why not use trunk for development and then a branch for sid? This
> is more or less how XSF  works nowadays.

Far too much of a big deal is being made of this. Here is the problem
in a nutshell.

We have a number of different versions of different kernels.
For some sarge is the head branch, for some sid is, and
for some experimental is. The typical SVN layout (which people
seem mildly obsessed with), puts whatever happens to be the
head branch in trunk, and everything else in branch - 
in our case per-distribution branches.

This isn't a big deal, except when stuff disappears into branch,
when you expect it to be in trunk.

It is also a bit confusing, when, say linux-2.6 in trunk was sid
yesterday, and today its experimental and the sid version has
mysteriously moved into branches.

So an idea that many of the people in the kernel team seem comfortable
with is moving everything that we are working on into trunk.

Then there is some debate about perhaps renaming trunk (mainly
to avoid the conitations that has), and how exactly to organise
the distributions within trunk.


One issue, that both approaches do not address very well, 
is the which branch is head problem. As I mentioned above,
for some kernels its sid, for some its experimental (or
perhaps we just don't release ones in that category) and for some
its sarge. 

To be quite honest, I am more worried about making sure changes
get put into all applicable branches, for instance a security
fix, often needs to go into all branches, sometimes of all
kernels. So it would be nice to make it really obvious where they all
are. And not have head and branches in completely different places.


-- 
Horms



Reply to: