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

Re: [kernel] r4732 - in dists: sid trunk



On Mon, 2005-11-07 at 12:03 +0900, Horms wrote:
> On Sun, Nov 06, 2005 at 05:45:16PM -0700, dann frazier wrote:
> 
> [snip]
> 
> > A little more ranting... I don't like that we're using a temporal layout
> > because it means moves are always happening.  svn lets us move stuff,
> > which is a great feature, but the way we're using it is an abuse of this
> > feature (imo).  Not only is it a pain for development when the world
> > changes behind your back (sometimes even making svn updates fail), but
> > it also leaves a confusing trail behind.  I feel sorry for anyone who
> > tries to dig through the archive trying to make sense of the history,
> > and anyone who tries to convert our repository into another source
> > control system.
> > 
> > To be fair, I didn't dislike the scheme at first - and it doesn't seem
> > too bad for more static stuff like sarge-security, etc.  But when things
> > are under constant development (dists/trunk, dists/sid) moves are just
> > happening too often.
> > 
> > To avoid being one that complains without providing an alternate
> > suggestion - what if we tracked things by upstream kernel version?
> > 
> > linux-2.6/2.6.12/
> > linux-2.6/2.6.14/
> > 
> > And if people want to have the dist information stored in svn, use
> > symlinks:
> > 
> > linux-2.6/2.6.12
> > linux-2.6/sid -> 2.6.12
> > linux-2.6/2.6.15
> 
> Your approach also seems workable, well at least more workable than the
> current situation. Though I'm not sure what happens when 2.6.15-rc2 gets
> incremented to 2.6.15-rc3. Do we just use 2.6.15/ from the get go?

I suppose that makes sense if we're really just tracking rc's to prep a
tree for when 2.6.15 is available.  But yeah, this proposal certainly
has its own idiosyncrasies.





Reply to: