Re: [Gnu-arch-users] [OT] Darcs data model

[Matthew Dempsky]

Juliusz Chroboczek <address@hidden> writes:

> Suppose that you have two patches A and B that modify different files,
> or separate parts of a file.  Intuitively, the order in which these
> patches are applied is pretty much irrelevant -- you could apply A and
> then B, or else first B' and then A' (where A' and B' are A and B with
> line numbers suitably shifted).  In darcs terminology, A and B /commute/.
>
> On the other hand, if D modifies lines that are inserted by C, D must
> be applied after C.  Here, C and D don't commute, in darcs terminology
> D /depends/ on C.
>
> In systems such as SCCS, RCS, CVS or Arch, patches are ordered (within
> a given branch) even when they commute.  In other words, even though A
> and B commute, they are stored in a given order, the ordering persists
> forever, and is something the user is aware of.

While the idea of patches automatically determining dependencies like
that is neat and all, I see a key problem with emphasizing the
usefulness of it.

Clearly patches should at least depend on previous patches when they
modify text added by them, but that doesn't mean two non-overlapping
patches shouldn't depend on one another.  If patch A adds a new
function foo, and patch B modifies some code to make calls to foo,
clearly B depends on A.

You're right that in an Arch branch patches are ordered even when they
(syntactically) commute, but I hardly think of that as a problem since
you can always set up multiple branches which (semantically) commute
and use the in-branch ordering to identify dependencies between
changes that Arch couldn't possibly take the responsiblity of
identifying on its own.