Re: What a modern collaboration toolkit looks like

[Mike Mattie <codermattie@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6701 bytes --]

On Sat, 05 Jan 2008 16:59:13 +0100
Andreas Schwab <schwab@suse.de> wrote:

> Richard Stallman <rms@gnu.org> 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)

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel