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

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

On Fri, Aug 03, 2001 at 01:37:08PM +1000, Greg Banks wrote:
>   This is part of the problem: that part of CVS' functionality is difficu=
lt
> to use and confuses people.  Most people can conceptualise linear revisio=
n 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.
>=20
>   But when the revision tree generalises, people's mental models start br=
eaking
> down.  How do you relate versions "1.5.1.6" and "1.7" ?   How do you expl=
ain
> sticky branch tags?  Then people have to start *thinking* about how they =
do
> things, and at this point they start making mistakes, usually resulting i=
n changes
> being checked into the wrong branch.  I've seen experienced, clueful soft=
ware
> specialists in a commercial environment make significant mistakes with CV=
S branches.
> What this does is generate confusion and more work for the people who hav=
e to
> clean it up; and no amount of explanation of "how it works" helps because=
 people
> just *won't* understand.
>=20
Versions aren't difficult to follow once the basic concepts are understood.=
 One thing
I'm kind of curious about though, is how you came up with the 1.5.1.6 numbe=
r. This
would indicate that a branch occured when the main trunk was at a revision =
of 1.5.
Though branch numbers are done in even numbers, starting at 2, so you don't=
 step on
the magic branch numbers. Perhaps you meant 1.5.2.6 to indicate the 6th rev=
ision in
the first branch off the main trunk from revision 1.5?

Relating 1.5.2.6 and 1.7 isn't quite that difficult.. one resides off a bra=
nch with
its own revision history, the other resides in the main trunk. Though why y=
ou would
be feeding revisions through the main trunk when things should just go thro=
ugh the
current stable branch is beyond me.

Sticky branch tags aren't anything revolutionary or complex either. I'm sur=
e if
people spent a few minutes alone with the 'cvs status' command, half this s=
tuff
would indeed not be an issue.

I've also seen many experienced, clueful software engineers having issues w=
ith CVS
branching. Most of these problems originated from not reading documentation=
, or
not knowing where to find documentation (which is another issue entirely). =
The
branching concept is nothing new or complicated, CVS just requires you to do
manually that which systems like BitKeeper do automagically.

I think the majority of your concerns stem from people not being able to pi=
ck up
on this stuff fast enough. Branches and tags are still part of the CVS basi=
cs,
and are only difficult if you make them so. A relatively simple concept is =
just
that, needless confusion isn't CVS's fault. There is also numerous document=
ation
available on how to do clean and proper branching.. such as the CVS Book, w=
hich
includes walk throughs and all that kind of fun stuff. A quick tutorial on =
the
matter should be suffecient IMO.

>   Remember, 18 months ago many of the LinuxSH developers had never used C=
VS and
> basic CVS features like automatic merge were new and exciting.  Part of t=
he process
> of selling CVS involved demonstrating how easy and simple it is, which me=
ant of
> course hiding the ugly bits like branches.
>=20
Branching is only "ugly" because CVS doesn't do it for you. CVS is a tool, =
not a
hold-your-hand-through-the-basics-of-source-control crutch. CVS does indeed=
 have
its problems, but things like branching are fairly well documented, and sho=
uldn't
be that hard to get ones head around after spending a bit of time playing w=
ith it.

>   For exactly two pre-determined branches which will diverge, the full po=
wer of CVS
> branches is not necessary.  Using two subdirectories of $CVSROOT is perfe=
ctly adequate,
> and is much easier to explain to people whose primary job is making hardw=
are work, not
> CVS finagling.
>=20
Using two subdirectories or two branches isn't really any different. If you=
 want
to do work on an experimental branch, check it out, and do your work from t=
here,
making sure that the sticky tag is set to the experimental branch, while
making sure you're doing things under the right tag.

I agree people should spend more time writing code than twiddling with CVS,=
 but
spending a bit of time on CVS now to save more time later seems to have eno=
ugh
benefits IMO.

>   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.
>=20
>   I like the idea of a drop-in tree, I think it's a huge improvement in m=
any
> ways, I even toyed with the idea internally at PocketPenguins.  My role h=
ere
> is devil's advocate, trying to ensure that M.R.'s proposals cover all the=
 issues
> and can stand up to counter-argument.
>=20
A drop-in tree can be done without CVS branches just fine, though CVS branc=
hes
would be a lot cleaner in the long run. If people don't like the idea of de=
aling
with CVS branches, so be it. That still shouldn't have any bearing on the
drop-in tree or CVS tag usage.

Regards,

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