Re: What a modern collaboration toolkit looks like

[Mike Mattie]

On Sat, 05 Jan 2008 16:59:13 +0100
Andreas Schwab <address@hidden> wrote:

> Richard Stallman <address@hidden> writes:
> 
> > Currently we recommend that people "build the source from CVS", and
> > we don't say "from the trunk" because that is a general convention
> > of CVS usage.
> >
> > If we used git, what convention would replace that?
> 
> It's the same, basically.  If you clone a git repository, your
> personal repository is automatically set up to track the default
> branch of the remote repository, which is normally the master branch.
> 
> Andreas.
> 

take a look at www.kernel.org. I use git for my linux tree. 

I am what you would call the end-user in this case. My use is alot
simpler with git.

When a release is pending I check the changelogs via gitweb, do various
searches for hardware and sub-systems of interest. If I like what I see
I simply cut & paste the git url into a git-pull and merge the upstream
changes.

On a regular basis I pull from two branches, the first branch being the
official linus tree, the second is usually 2.6.x.y for patch releases.

Occasionally I need to debug a kernel problem with a pre-release. When
this happens if the developer for the sub-system is using git I can
pull fixes from his tree while we are diagnosing the problem. Once it
is fixed I don't have to revert the changes before I pull from the official
repo again, because the maintainer requests a pull from linus, it gets merged,
and git doesn't barf on previously merged changes.

In fact during this discussion I have noticed a key point that has not been 
mentioned.
If RMS is wondering how a project is lead with a distributed system the answer 
is
the convention of asking for a pull.

I don't think anyone "pushes" changes on Linus. When they have something that 
is in shape
for him to review they request via e-mail a pull and give the git URL. Linus is 
then
free to look through the history of their branch. He can see not just the work, 
but the history.
That includes all the changes, bugs, and features. By reading the history he 
can get a much
greater sense of how it developed, not just a diff. If he likes it, he pulls 
it. If not they
can keep at it and ask again later. When he pulls he gets the full history.

CVS is crippled in that there is no way to record changes before commit. I 
personally do
not like CVS like systems because it puts a huge burden on the developer that 
actually
works really hard to do a clean merge for review.

What I consider a clean merge for review to be is this: Broken up into changes 
where each
change can be described succinctly by a changelog, and the change must not 
break compile
or regress. 

here is a little constrast sketch:

bad commit:
add subsystem foo , with new data structure bar, modifying existing code baz to 
use new data structure bar.

Good commit:

1. add new data structure bar
2. modify baz to use new data structure bar
3. add subsystem foo.

Notice how in the good commit the maintainer of baz can evaluate the new data 
structure without wading
through my new subsystem foo which he probably doesn't care about. If CVS and 
DVCS systems where compared
to writing CVS would not have topics or paragraphs, just one huge body of text. 
Changes in DVCS systems
can be broken up, like a body of text into paragraphs so that people can 
understand them better.

Because CVS cannot record changes in the working copy you have to do one of two 
things:

A. finish the entire work and publish as a single commit. This alternative is 
so broken you actually
   have to backup your working copy changes yourself.
B. break the commit up into valid changes and try and maintain a diff series in 
the working copy
   until you can submit the sequence. Again backing up yourself.
C. use a branch.

Of course people who use CVS will say C is an entirely valid option. It does 
work. But it discourages
casual development and definitely would discourage me. I don't like to make 
proposals without
code to show. Often until the code is fleshed out I don't have the facts to 
make a proposal.
With CVS I have to get a commit bit, get a branch (sounds like paperwork), and 
finally start
hacking away. I consider this high risk because I have to declare my success 
(proposal + commit bit + branch)
before I know if the idea will even work.

I would much rather hack away on any distributed VCS where I can pick the good 
idea from the dozens
of ideas that seemed good but did not pan out. When I would go to "request 
pull" or merge I can
show the entire history of the development.

DVCS are not perfect, but they at least make what I call a good commit possible 
without having to
do what I consider absurd labor. When I have to work on a project using CVS or 
even SVN I spend
a huge amount of time manually slicing and dicing diffs in diff mode. If 
anything goes wrong in
the diff sequence I am in big trouble so I also have to keep full copies at 
each "change point".
At that point It's not a reversion control system for me, it's just a 
publishing tool. All of
the changes have to be maintained by hand in diff-mode.

What I call good commits has two key points. It feeds changes incrementally for 
both review and
testing. Who wants to try and test a huge chunk of code dropped in a single 
commit ? Doing things
the right way usually pays off even in ways you don't anticipate, like 
git-bisect. I have personally
used that to track down a problem with a IDE driver. I found the broken 
changeset in something like six
reboots. The fix was in the Linus tree within days.

I don't think it works at all to try and describe git in terms of CVS. In fact 
dictating how you
merge by version control system is kinda supsect as well. The goal should be to 
turn in high
quality merges, incrementally reviewed, incrementally merged and tested. Any 
change that breaks
the compile or test-harness is sin plain and simple. If a project can't 
maintain that standard
with their tools then their tools are a problem. If the developers are so 
skilled at flaking
diffs from their working copy like cavemen flaking arrowheads from stone, then 
there is no
problem.

On the other hand if merging changes is a problem, then there is a *big* 
problem. I don't think
merging is something you do for release, it's something you do to integrate the 
work of a team.
If you can't merge you can't work together. If anything branching is for 
release, not development.

My 2 cents at least. Please don't take any offense from any of these 
statements. No person
or caricature was harmed in the writing of this mail.

Cheers,
Mike Mattie (peanut gallery)

signature.asc
Description: PGP signature