<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> Stefan Monnier wrote: <blockquote cite="midjwvzlt0u0t2.fsf-monnier+emacs@gnu.org" type="cite"> <blockquote type="cite"> <pre wrap="">hard to improve Arch to do it really well -- why not spend volunteer labor on that, rather than on messing around in some ad hoc way with some other DVCS? </pre> </blockquote> <pre wrap=""> I already spend more than my fair share of volunteer time, thank you. </pre> </blockquote> I mean the project as a whole, not you personally. The project sets goals or asks generally that certain tasks get done, such as setting up a new repository or creating a gateway between two DVCS systems.   It's that "spending" I'm asking about. I see a sort of technical paradox going on: The project eventually decided to use a DVCS and then decided on bzr.   So, what problems are left after that?   Well, someone has to set up the repository -- ok. But the new sub-problems also include importing history, setting up gateways to other systems, trying to make sure that history stays in sync across gateways, building patch-flow tracking mechanisms, etc. The paradox is that having picked a DVCS, the remaining sub-problems add up to "implement 80% of a DVCS system." Hmm.   That seems an odd tactic. <blockquote cite="midjwvzlt0u0t2.fsf-monnier+emacs@gnu.org" type="cite"> <pre wrap="">BTW, in order to handle merges really well, I think it's important to distinguish merges from conflict resolutions: i.e. a merge should be an operation in the repository which results in a new revision that may contain conflicts. Conflict resolution would be done by checking out that revision, resolving the conflict and then committing the result as a new revision. I.e. distinguish "pure merges" from non-pure ones by turning every merge into a "pure merge". </pre> </blockquote> Sure, that's an important feature.   It's not a feature that needs to be built in to a VCS.   It can be implemented portably across VCS systems. I will say this: you are giving me "the itch".    I'm very deep into another project right at this moment but I will see if I can find a few hours to write Arch 2.0 to toss into consideration late to the process, unproved in the field, and otherwise a dark-horse, wild-card, crazy-uncle-in-the-basement candidate.  It'd probably take less time than trying harder to explain how to build it. -t </body> </html>