Re: [linuxsh-dev] [RFC] LinuxSH code reorg

[Greg B. <gb...@po...>]

Paul Mundt wrote:
> 
> On Fri, Aug 03, 2001 at 11:14:40AM +1000, Greg Banks wrote:
> > > [...] As the drop-in trees are much smaller than the full kernel,
> > wouldn't it be simpler to have two CVS modules, one each for stable and
> > experimental trees?
> >
> Er, this is exactly what the branches are for. [...]

  I'm not arguing from ignorance here, but from bitter experience.  See below.

> >   You may be able to tell, I've had *bad* experiences with CVS branches before.
> >
> The majority of bad experiences come from people improperly setting up/using
> CVS branches. It's amazing the number of repositories out there that aren't
> being run properly at all, simply because people don't know how to use CVS.

  This is part of the problem: that part of CVS' functionality is difficult
to use and confuses people.  Most people can conceptualise linear revision trees
and deal with the practical issues of updating, adding files, and checking
in changes.  It's easy to understand how revisions "1.3" and "1.7" relate;
the numbering scheme appears (deceptively) to be what they're used to, and
it maps easily to the time dimension.

  But when the revision tree generalises, people's mental models start breaking
down.  How do you relate versions "1.5.1.6" and "1.7" ?   How do you explain
sticky branch tags?  Then people have to start *thinking* about how they do
things, and at this point they start making mistakes, usually resulting in changes
being checked into the wrong branch.  I've seen experienced, clueful software
specialists in a commercial environment make significant mistakes with CVS branches.
What this does is generate confusion and more work for the people who have to
clean it up; and no amount of explanation of "how it works" helps because people
just *won't* understand.

  Remember, 18 months ago many of the LinuxSH developers had never used CVS and
basic CVS features like automatic merge were new and exciting.  Part of the process
of selling CVS involved demonstrating how easy and simple it is, which meant of
course hiding the ugly bits like branches.

  So let's *not* start confusing the people who generate the actual useful working code.

  For exactly two pre-determined branches which will diverge, the full power of CVS
branches is not necessary.  Using two subdirectories of $CVSROOT is perfectly adequate,
and is much easier to explain to people whose primary job is making hardware work, not
CVS finagling.

> > 1.  procedures are feasible
> > 2.  everyone understands how they work
> > 3.  Niibe-san agrees with it
> >
> #1 should be taken care of when #2 is done properly. #2 could easily be
> acheived with a test tree and some documentation outlining how to use it.

  Yes.

> #3 would follow #2 and #1 being successful, or so I would think. Though that
> all depends how much Niibe-san likes drop-in trees and CVS branching/tagging.

  Yes.

> > > [...drop-in tree...]
> >   I agree, that's why the question is not "can it be better?" but "will it work?".
> >
> It's worked for everyone else, so I don't see it as being a hinderance here.

  Yes.

> I guess we can't say one way or another until it gets tried.

  Yes.
  
> Breakage is going to happen regardless, it's unavoidable. This isn't CVS's
> problem, this is something that's going to happen in any experimental tree.
> (Note: that's why it's experimental, not stable). [...] I don't see how CVS
> makes this a problem.
> 
> Perhaps I'm misunderstanding what you're getting at,

  Just trying to clear up my own sloppy use of terminology.  I was using
"manual merge" to mean the entire process of CVS automatic textual merge
plus manually fixing the breakages.  In your last post you seemed to be
interpreting "manual merge" in the narrower sense of doing the textual
merge manually.  This was a reasonable interpretation, but not what I
meant (oops).

> but I don't see
> anything you've listed above as being a problem with CVS or the drop-in tree
> design. 

  I agree.  These problems are inherent and no version control arrangement
will make them go away, and I don't intend to imply otherwise.  They're not
a problem of CVS or of either a full or drop-in tree.

  This was the point I was trying to make to M.R., who seemed to believe
that a drop-in tree would somehow magically make these problems disappear.
I quote:

Greg Banks>   Also, this same recurrent breakage means that the drop-in would
Greg Banks> practically only work with a single mainline kernel version, maybe two or
Greg Banks> three if we're lucky.  How do you propose to manage that?

M.R. Brown> As long as the drop-in tree can be easily sync'd with mainline patchlevels,
M.R. Brown> and we can figure out and/or fix why we get continuous breakage, this won't
M.R. Brown> be an issue.

  Afterwards, he mentioned the AGAINST-x.y.z file, which addresses the issue.

> These look like nothing but general issues that arise from any kind
> of kernel work across multiple revisions, and isn't something that can be
> avoided.

  Yes.

> CVS makes a lot of this a lot cleaner, as it does a lot of the
> work for you, you're just required to do the cleanup on stuff that rejects
> or stuff that breaks afterwards.

  Yes.

> Plus, with proper tagged branches, it's
> a lot simpler to track the history of things and follow API changes more
> closely.

  I think we agree on the value of (normal) tags, but disagree on the value
of branches.

> Try doing that in the current tree.

  I'm not trying to defend the current setup (even though I was one of
the people who argued for it and set it up).  The most I will say for the
current setup is that it was an improvement at the time.

  I like the idea of a drop-in tree, I think it's a huge improvement in many
ways, I even toyed with the idea internally at PocketPenguins.  My role here
is devil's advocate, trying to ensure that M.R.'s proposals cover all the issues
and can stand up to counter-argument.

Greg.
-- 
If it's a choice between being a paranoid, hyper-suspicious global
village idiot, or a gullible, mega-trusting sheep, I don't look
good in mint sauce.                      - jd, slashdot, 11Feb2000.