[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Bazaar 1.3 preview
From: |
John A Meinel |
Subject: |
Re: [Gnu-arch-users] Bazaar 1.3 preview |
Date: |
Fri, 01 Apr 2005 10:05:40 -0600 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
David Allouche wrote:
On Fri, 2005-04-01 at 01:09 +0000, Mikhael Goikhman wrote:
I didn't try baz 1.3 preview, but I would like to know about the status
of several issues.
1) Don't you think "tree-id" command is misnamed? Use "tree-rev" name
if you feel "tree-revision" is not short enough (I don't feel so).
I concur.
Well, one thing that I've notice digging through the baz code, is that
they actually are trying to restructure it, to potentially allow changes
to the namespace. I can't say where they are going, but some of the
structures look like a good place to change from c--b--v to maybe
c--b--v--s, or c--b1--b2--b3--v, or something like that.
So it might be possible that because of a potential namespace
restructure they are looking to use a more generic term "id" then
sticking with revision.
The internal structure they use is called arch_patch_id, which calls
fully qualified version name == branch. So internally the place where
patches go is a "branch".
2) The flat-revision subdirectory structure in ~/.arch-cache leads to
huge directories, this is not scalable. Is not version/patchlevel
structure more balanced and more consistent?
I agree, the arch-cache hierarchy should use versions containership
because:
* the cache hierarchy groups revisions by archive names, so there
is already a coupling with the namespace hierarchy.
* just grouping revisions by archives leads to too big
directories, that's not a good use filesystem storage.
Baz hackers?
I also fully agree that they should split again at the patch_level.
However, I think the trick is that they are using the pun of
a/c--b--v--r so that you can just say
dir = str_cat (cache_dir, fqrevision);
Without having to parse fqrevision. Again, this might be because they
are thinking about a namespace restructure.
I'm being pretty speculative here, though.
And I think they could still do:
dir = str_alloc_cat_many (0, cache_dir, "/",
arch_patch_id_branch (fqrevision), "/",
arch_patch_id_patch_level (fqrevision));
Since they declare arch_patch_id_branch as the location where patches go.
John
=:->