Re: [Gnu-arch-users] arch lkml

[Tom Lord]

    > From: address@hidden (Eric W. Biederman)

    [topic is roughly: does arch botch merging vs distributed development]

    > I may be behind the power curve, as I have only skimmed what is present
    > in arch but I think I can explain myself.

No sweat.  On our side, i'm just a couple of days away from preX
release that has an updated tutorial -- the current version is
annoyingly, ever so slightly, out of sync with the sources.  After
that release, I think the tutorial can be a pretty decent way to catch
on.


    > So the cases that I believe are important for being distributed are
    > multiple repositories, and merging multiple branches from multiple
    > repositories into one branch.

These are things arch does very well.


    > As I understand it when you merge between two arch repositories, you
    > don't keep both parent versions.  When merging between multiple
    > repositories this makes finding what is common between the versions
    > difficult. 

I can only guess what you mean by "don't keep both parent versions".
Here's my guess.

My vague understanding about BK is that if you and I both use it, we
both have repositories.   If I'm going to merge in some changes from
you, what happens is that the history of your changes is copied into
my repository from yours, and then the merge proceeds.   Arch doesn't
copy history that way, and so you say "don't keep both parent
versions".   Is that about right?

Arch isn't trying to duplicate the BK architecture -- arch's is
better.  We _do_ solve the same problem -- just slightly differently:
better;  more flexibly.

In arch world, the boundaries between archives (roughly what BK calls
repositories) are transparent.   We don't need to duplicate that
history -- it's still there, in the original archive.   You can
interact with it from trees from your archive with no problem.   You
can think of all the arch archives as just one, big archive.

In BK world, when stuff is copied from my repository to yours, I get a
local copy.

In arch world: you have a choice.   If you are comfortable with the
network connectivity between us -- no need to copy.   arch will just
hit up my remote archive whenever you do something that needs that.
On the other hand, to make things faster or because you don't trust
our connectivity, you can _mirror_ my archive to your local
environment.   The mirror acts as a stand-in for my archive.

So, the combination of mirroring my archive, and then just merging
from it in the usual way -- that most closely resembles what I
understand BK to be doing when you merge.   In arch, though, the two
acts are separable:  you can mirror without merging, and you can merge
without mirroring.   

As for "comparing things" across archive boundaries:  as I said, to
arch, archive boundaries are basically transparent.   There's no
important difference between comparing things within your archive, or
comparing things between our two archives.



    > Given that it didn't quite look like star-merge was working when 
    > I surveyed arch, you may fixed the issues I have seen.  But my
    > impression that fixing that one problem would just about take
    > a from scratch rewrite of arch.

No idea what you're talking about there.

It's funny you should mention star-merge.   I'll mention that the
abstract idea of "merging" doesn't reduce to a single operation.
There's quite a few different ways to merge two sets of changes.  Most
systems, don't know if BK is one of these, provide essentially just
one.   arch's merging support is, in fact, quite powerful -- and
star-merge is just one of the tools in the toolbox.


    > If I am misunderstanding something please let me know.

Well, there you go.

-t