Re: [tlug] Open-source repository question

[John Fremlin <john@example.com>]

Stephen J. Turnbull wrote:
> Of course.  In a sense every VCS must have an implicit theory of
> patches (and unfortunately in Darcs's case, it doesn't entirely match
> the explicit one).

Where does the implicit theory of patches diverge from the explicit (and 
 misguided) one?

To achieve darcs' goals, it would have to understand rather more about 
the meaning of the changes than it currently does or is feasible. This 
would involve a very interesting and much more language-specific theory 
of patches.

> Unfortunately for git's theory, it suffers from the same bug that
> Darcs does, namely the assumption that changes that do not conflict
> textually do not conflict semantically.  For example, it's quite
> possible in git to commit a change to a function prototype in foo.h
> without making the corresponding change in foo.c or in any callers.
> You will of course get no warning until you compile.

That is not exactly what I was trying to get at.

Namely, I think the idea of operation of git is that major changes have 
their own branch name and are regularly rebased onto the master branch 
and then eventually merged.

There isn't any need for the machine to worry about whether one branch 
conflicts with another, that's for the user to figure out.

Therefore, git hasn't claimed anything that it cannot deliver -- it's 
theory is all about how it manages its database, and is correct.

> Now, if you're Linus (or on a more personal note, Curt), you can keep
> all that in your head.  I think that's why Curt can get away with
> deprecating cheap branching as he did.  But when you get to the scale
> of the Linux kernel, it don't work so well, and you start needing
> cheaping branching so bad you invent it. :-)

Even with smaller scale projects (four or five people) it's incredibly 
useful to be able to branch quickly to make changes that benefit one 
feature but break a lot of others.

Whenever I am working with a team, I tend to have several branches (all 
checked out), one for each feature plan. When one is ready, then I 
rebase it to the main branch, and commit the sensible diffs.

> You could also argue that that is not the VCS's job.  But I think
> that's what's buzzing around the back of Linus's head when he keeps
> insisting "git is just a stupid content tracker, it's not really a VCS
> or SCM".

I suppose I should have been clearer about my notion; by theory of 
patches I meant something rather grander -- in some sense the 
algorithmic scope of the version control system.

For example, CVS worked each change considered as applying to one file 
at a time, Subversion tries to handle multiple files, git tracks 
content, and darcs attempts to consider changes to be first class objects.

The theory of git would involve a lot of talk about blobs and checksums, 
so you are quite right that it shouldn't be called a theory of patches 
but something else.