[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] arch lkml
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] arch lkml |
Date: |
Thu, 25 Sep 2003 13:04:19 -0700 (PDT) |
> From: Andrea Arcangeli <address@hidden>
> On Thu, Sep 25, 2003 at 11:15:33AM -0600, Eric W. Biederman wrote:
>> poorly and is not distributed. SVN is not distributed. ARCH is
>> barely distributed and architecturally it makes distributed merging
>> hard. [..]
I think (Eric) that you'll find that many of us believe pretty much
the opposite of what you say about arch. That raises the
interesting question: what the heck do you mean?
(If we're missing something fundamental, let's hear about it --- if
you've misunderstood something, perhaps we can clear that up.)
> actually it seems I can use it for my tree too, after I modify it
> to be able to tag into a plain source tree forked with hardlinks
> (something I certainly couldn't do with b*tkeeper), and a way to change
> the patchsets internally (and a way to extract all the patches ordered
> with meaningful names for marcelo and other trees not based on
> arch).
I don't quite follow you (Andrea) there. Perhaps you could explain further.
> This my proposal to change arch to be able to hook into a random tree in
> the filesystem (instead of a base-0 tarball), could radically change the
> way of doing distributed development, in term of resource savings (I bet
> that would be an order of magnitude better than bk too, I mean, I've
> lots of tarballs open anyways here, since various trees starts on top of
> official tar.gz packages, not bkcvs, I so I could save gigabytes of
> space and dcache efficiency with that feature, even across the non arch
> usages that are the most common to me at the moment). The hardlinks will
> make an huge difference and it'll be natural the way arch is designed to
> take the best advance of them as soon as we can hook into an unpacked
> tar.gz.
Again, I don't _quite_ follow you however, perhaps this is relevent:
You can use `mkpatch/dopatch' (the arch changeset tools) more or less
independently of using arch. `dopatch', in particular, "does the
right thing" when patching a tree that is the clone of some other tree
created using hardlinks.
> arch looks infact more an 'archive for patches' than anything
> else.
Archive, cataloging system, and _set_of_tools_for_manipulating_ in
various useful ways, yes.
> But in terms of automated "merging" design between two separate
> distributed trees ala b*tkeeper, the problem after you run into rejects
> is just unsolvable better than 'arch' already does, as far as I can
> tell. I don't see how b*tkeeper can do better just because I can't
> imagine anything better possible to do during merging (I can't use bk
> myself so I can't know if it does it differently). And not even
> b*tkeeper can know that the merging went right like an human can do,
> there's no way it can understand the sematics of the code during merging
> (actually defined as star-merging as from the arch specifications). If
> one product does better than the other given the same development
> simulation, it could be simply that its heuristics are less strict (i.e.
> simular to diff -u0 vs diff -u vs diff -u10)
I really don't know much about bk's merge operators -- but it is
highly likely that (syntactic trivialities and GUIs aside) they come
out to be a subset of what you can do with arch. Andrea is right
with his suggestion (my paraphrase) that we've nailed that space.
(The syntactic triviality: conflict mark-ups that look like unified
diffs, is in the patch-queue. GUIs: I think we have all the
arch-side bits lined up and now its mostly a matter of someone making
the interface to any of the existing graphical merge tools fit
smoothly into use.)
> Then there are quite tons of issues with the on disk format, I feel the
> gzip slows down things, I didn't try to remove it, but that's my
> feeling. Those are small patches, and small files, a tar is sure a good
> idea, but gzip I think should be optional.
They reduce network traffic in a natural way. In purely local
set-ups, we have not seen any evidence that they impact performance in
any way worth worrying about.
> About the inventories I would simply go forcing the extended mode, that
> force the equivalent of cvs add on every file archived, this is much
> prefereable IMHO because in a big thing like the kernel there's lots of
> garbage with all sort of names, and so the commit operation could never
> get right which files to checkin and which not. It's much easier to
> consider only the files explicitly added to the repository with an
> 'arch' command during the commit/update/reply etc...
Do you mean `explicit' mode? I think it can be configured to do
pretty much what you want.
> About other misc comments I don't see:
> 1) the difference between update/reply/merge-star
"star-merge".
> 2) why there isn't an automated make-log + vi + commit command
> 3) why the +/= in front of the names
> About the {arch} directory, using the { is a great idea to reduce
> dramatically the namespace pollution. I've never seen a { in a directory
> before ;)
> I also had a problem with cvs2arch, it worked fine for a repository (not
> the kernel, a small one) but not for another. It happened on a directory
> that didn't exist in the original cvs import, then it was created over
> time. At the time the directory is created in cvs, cvs2arch fails and
> says the directory doesn't exist in the arch data directory.
I wonder if the new gateway mechanisms BM is working on provide an
alternative worth considering.
-t