* Adam Megacz <[EMAIL PROTECTED]> [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
signature.asc
Description: Digital signature
_______________________________________________ darcs-users mailing list [email protected] http://lists.osuosl.org/mailman/listinfo/darcs-users
