Arch's merge history handling
Thomas Lord
lord at emf.net
Sat Mar 15 16:43:32 GMT 2008
Stefan Monnier wrote:
>> 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?
>>
>
> I already spend more than my fair share of volunteer time, thank you.
>
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.
> 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".
>
>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20080315/3a77bfa3/attachment.htm
More information about the bazaar
mailing list