Daniel Carrera writes:
> It is mighty hard to come up with a good label
True, but that has nothing to do with being able to recognize one that
isn't so good.
> 'Theory' and 'Algebra' are intimidating.
"Algebra" is intimidating, period. But "theory" is only intimidating
if you need to know it. Otherwise, it's comforting to know that
somebody else has a proof.
> Plus, ["smart patch"] is something that any SCM user will resonably
> understand.
Er, I'm a counterexample. I know what diff(1) and patch(1) do, and I
believe that they are quite reliable. I do not know beyond that what
a "smart patch" might be, and simply being given examples worries me:
it makes me think maybe I should book up on the theory before trusting
it with my data.
> I did not write "Darc" anywhere, I wrote "Darcs'".
Which is the plural possessive of "Darc".
> When a word ends in "s" (Jesus, Darcs) the possessive is formed by
> appending an apostrophe only and keeping the pronunciation
> intact. I didn't invent this rule. I just followed it.
Indeed, you did invent that rule, because it's wrong. In English,
singular words, regardless of the trailing letter, take the suffix
"'s" to form the plural (unless they're irregular, like I -> my, or it
-> its). Plural words that end in s have their plurals formed with an
apostrophe and no s.
> Could you suggest an example of (b)? I'm sure it would be useful in the
> documentation.
See my other post.
> There is a small kernel [of patch theory] that is relevant to users.
True, and it belongs in the manual, and in the FAQ. It doesn't belong
anywhere it might frighten away the fish.
> I already lost confidence. How do I know if my project fits your
> definition of sane?
You're playing word games, because you have no text in front of you.
Of course, I wouldn't use a word like "sane" at all, that's way worse
than "smart" as you correctly, if inappropriately, point out. I'd
describe what I mean by sane. Something like this:
In order to merge two branches, Darcs must often rearrange patches
in one or both branches. An example is to deal with what patch(1)
reports as an "offset" when applying a diff: preceding lines in
the file have been added or subtracted. But Darcs is reliable
because it's based on a rigorous theory of patches, which allows
it to calculate both the necessary adjustment to the patch and the
context of application, and report a conflict if the resulting
application is less than perfect.
There are merge problems that Darcs can't help you with. Patch
theory is not a substitute for a review process which confirms
that the semantics of the merged program are correct. For
example, two patches that update the same constant to the same new
value rarely conflict, but imagine a case where the constant
counts the number of elements in an enumeration. Suppose two
programmers each add one new enumerator and increment the counter
by one. Net result of a merge: two new elements added, but the
counter is only incremented by one. But human programmers make
related mistakes all the time, failing to update the counter or
simply miscounting the enumeration's elements. It's not the VCS's
responsibility to deal with such *semantic* conflicts.
On the other hand, Darcs is absolutely reliable on the mechanical
transformations. It will insert new text on the right line,
delete text from the right line, etc, far more accurately than
patch(1) can do, because Darcs "knows" *why* an "offset" or "fuzz"
occurs, and can compute *how large* it should be. If it doesn't
find what it expects, it will report a conflict.
As usual for me, I think it's too verbose and a bit stiff. But maybe
you can do something with it.
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
