Arch's merge history handling

[Thomas Lord]

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