[gobolinux-users] Call for volunteers: would you like to be a recipe committer?

[hisham.hm at gmail.com]

On 7/20/07, Samuel A. Falvo II <sam.falvo at gmail.com> wrote:
> On 7/20/07, hisham.hm at gmail.com <hisham.hm at gmail.com> wrote:
> > I don't. No algebra for patching will ever be able to cope with the
>
> Darcs' patch theory has nothing at all to do with program semantics.

And like I said, that's its inherent (and unsolvable) limitation.

> Program semantics and the order in which *independent* patches are
> applied are thoroughly unrelated.  The keyword here is independent --
> meaning, patches which do not depend on other patches to be applied.

The problem is that true independence cannot be verified without
semantic analysis. A change in file A can affect indirectly a value
that may or may not be used by part of the program written in file B.
Two separate patches in those files apply without conflicts. Things
that are "simple decisions", like MJ said, syntactically speaking, may
be complicated decisions (or worse, simple-but-obviously-wrong
decisions) semantically, and that's where the auto-merger's
fascination goes down the drain, at least for me.

> Program semantics is a unit-testing and integration-testing issue.  If
> merging a patch breaks a build, roll back the changes.  It's just as
> easy to do with darcs as it is with CVS or SVN.  If you're attempting
> to use your SCM tool for semantics checking, you've got bigger
> problems.

I'm definitely not. And don't see my comments as attacks on Darcs; my
skepticism applies to merging policies of all SCM programs. What I
don't like is the policy of "let it merge and if it didn't break (read
"if the test suite didn't notice the breakage") then fine". I'd rather
have the SCM not let the user commit something if their local tree is
not up to date with the repository they're committing to. That's the
only way to ensure semantic correctness (you can't ensure that if you
don't know what's in the codebase you're committing your code to -- "I
don't know if this will break the program, hopefully the test suite is
perfect enough to catch it if it does" doesn't sound like a
responsible approach  for programming to me).

Anyway, as interesting as this discussion is, I don't believe anyone
is planning to switch revision control systems in the project anytime
soon (other than the already planned move of the tools from the
Savannah CVS to the gobolinux.org SVN sometime in the future). So I
guess we're heading into offtopic territory a little.

-- Hisham