[darcs-users] *practical* differences between darcs' patch model and git/mercurial's?

[Tristan Seligmann]

* Adam Megacz <megacz at cs.berkeley.edu> [2007-10-21 00:46:34 -0700]:

> I suppose this might matter if you have multiple developers performing
> identical nonconflicting merges independently.  In a situation like
> that, having each developer generating their own merge-patches could
> be bad, because then locally generated patches would seem to have
> different histories (ie include different mergers) when in fact the
> set of nontrivial patches in the history of each local change is
> identical.

This is actually quite important for the workflow I have in several of
my projects. The way we work is that the "core" developers each have a
"public" repository or collection of repositories (in the case of the
non-public projects, this just means that they're accessible by the
other developers) where they push patches to once they're ready for
consumption by others. Each developer will periodically pull from the
other developers, dealing with conflicts if necessary (either by
recording a resolution patch, or amending his unreleased patches to
avoid the conflict). As you point out, with other systems, this would
result in the separate merges conflicting; which means you would need a
centralised synchronization point of some kind where merges flow
through, to avoid this.

With darcs, we can quite happily maintain a "ring" structure at the
core; this ring may then have spokes leading out from it, as certain
core developers take responsibility for merging patches submitted via
the bug tracker, or from contributors maintaining their own public
repository, but who are not considered "core" developers. In cases where
it is desireable to have a single "combined" respository to point casual
users at, I've set up a cronjob to pull from all core developers into an
"integration" repository in a conservative manner (if there are any
conflicts, the pull is aborted). The difference is that anyone can setup
such an integration repository without causing any difficulties, so the
setup still remains decentralized / distributed.

> Unfortunately, it seems like the case where the theory of patches
> offers an advantage happens to be precisely the case where darcs falls
> over because of exponential time problems.  So perhaps there's
> actually no difference in practice.

In my opinion, it's not too hard to avoid tripping over that case if you
don't allow branches to drift too far apart, and take precautions to
avoid the problem (for example, we tend to prefer amend-record over
leaving mergers around in patches, where possible). This is obviously
highly dependent on your usage patterns, though, and I'll admit that
none of my projects are particularly large; the largest is currently at
2297 patches comprising 25MB of compressed patch data, with the pristine
copy totalling 73MB of data.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.osuosl.org/pipermail/darcs-users/attachments/20071024/b619d448/attachment.pgp