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

[Paul M. <pm...@mv...>]

On Wed, Aug 01, 2001 at 09:32:29PM +1000, Greg Banks wrote:
>   So, when 2.5 is released, we start up a second drop-in tree
> for 2.5.x, while keeping the first 2.4.x drop-in tree?
>=20
>   What happens if 2.5.x is released before this gets organised (a real
> possibility)?  Do we then generate two seperate drop-in trees?
>=20
This is just a matter of maintaining two drop-in trees. They could just
be tagged as development and stable branches and be dealt with accordingly
under CVS. The PPC tree uses the same sort of convention, except they don't
do drop-in trees, and they use BitKeeper for source control.

This isn't really that big of a deal.. the best way to do it would be to ha=
ve
one person handling the stable, and someone else handling the experimental.
Either way, dealing with a drop-in tree cuts down maintenance time drastica=
lly.

When Linus drops a new tree on kernel.org, you simply look at the changes t=
hat
effect the files in the drop-in tree, and update them accordingly. This is
definately much less of a hassle then having to push forward the entire tre=
e,
as only the files that we're concerned about get modified.

In addition to this, it might be useful to start using proper CVS branches
and tags in CVS to make maintenance and such easier. ie, everything can be
under the same module in CVS, and newer revisions are simply inserted under
their own tag on their respective branch.. with the head always pointing to
the current stable.

> > Now the argument may be "why abandon the current full kernel tree then?=
"=20
>=20
>   I think the argument is "how can we make a drop-in tree workable for us=
?".
>=20
You would have to think long and hard about any disadvantages to a drop-in
tree that you wouldn't have to an entire tree. With the drop-in tree design,
you only ever touch that which is necessary to be modified by the tree. The=
re
is no reason to track other changes in the tree, as they don't concern the
tree, and are just a wasted effort.

> > As long as the drop-in tree can be easily sync'd with mainline patchlev=
els,
>=20
>   I don't see how.  It will require someone -- almost certainly Niibe-san=
 --
> to do frequent time-consuming merges.  Just like he does now.  The differ=
ence
> is that the final check-in will be much smaller.
>=20
Manual merging should be nothing short of a last resort. CVS deals with
branch merging just fine for the most part, and the few rejects it leaves
can be cleaned up by hand afterwards. It's totally counter productive to do
merges by hand of everything when the source control tool can deal with the
majority of it for you.

> > I'm going to ask James Simmons of ruby and linux-mips how he keeps his
> > trees in sync with the mainline kernel.  Paul M., if you're reading thi=
s,
> > do you have any suggestions regarding this?
>=20
>   Good idea.
>=20
I'd say just let CVS do its job, fix by hand that which CVS can't deal with,
and keep everything sanely tagged and under the proper branch. Maintaining
multiple revisions of something under a module in CVS isn't anywhere near
as complicated as people seem to think, after all, it's what CVS was design=
ed
for.

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.