Re: [Gnu-arch-users] GNU Arch review - am I accurate?

[Rob Weir]

On Thu, Mar 04, 2004 at 05:42:16PM +0000, David A. Wheeler said
> Thanks for all the feedback - here are a few replies.
> 
> When I said:
> >> * Is anyone currently working on automated caching?
> 
> Jan Hudec replied:
> > If you mean automatic creation of cached revisions, I have not
> >heared about it, except it's a trivial shell script to set as hook.
> 
> What I want is for the tool _defaults_ to "do the right thing".
> E.G., "every X versions or when the patches are Y% of the previous
> cache/baseline, create a new cache, and delete the Zth
> old automatic cache since it probably isn't needed".
> Manual control over caching, and controlling various performance
> parameters, are useful.  But by default, arch should take advantage
> of the information it has available to it, and do the "right thing"
> automatically to give reasonable performance.
> 
> I shouldn't have to set up hooks, or give caching commands, in
> the normal case just to do cache management... it should only
> be necessary for special circumstances.  The Linux kernel gives
> me all sorts of control over scheduling, but normally it
> divines the "right thing to do" and I don't have to touch it.

This is a good idea, but it does require someone "profiling" arch usage
to determine when caching is a good idea.  A good non-coding project for
someone would be to at least systematically collect data for performing
various operations on various sized archives (both byte- and
revision-sizes) with cacherevs at various points.

Automatically cachereving each revision as it is committed and deleting
the previous one would seem to be a decent way to boost "initial get
time", at least for small trees.  Just don't push it to your mirrors :)

> Although it's not as serious, the leading "=" triggers a bash bug,

When is = used in arch filenames, aside from {arch}/=tagging-methods?

> It's probably hopeless to change now, but filenames with "{}"
> like "{arch}" are a real pain in C shell.  "cd {arch}" and
> "vi {arch}/whatever" won't work, for example, because "{}" are
> globbing characters that C shell normally strips
> (you have to quote the filenames).  Since people shouldn't
> normally edit anything inside {...} directories, and it'd be
> horrendous to change, I guess that's probably not worth changing.

{arch} is embedded in all existing changesets, changing it would be...
messy.

> When I said:
> >> * Is there any reason that "mv" and "move" couldn't be the
> >> same thing (and let mv-id or an mv flag be the id mover)?

I did ask Tom when I implemented "mv" if it should replace "move" or
not, and he said to leave it; he may well have changed his mind by now,
however.

> I asked:
> >> * Has anyone thought about the "signing of signing" issue
> >> (A signs A's code, B accepts it, C accepts B's, and we
> >> have a chain of signatures from all 3 showing the transition)?...
> 
> Jan Hudec replied:
> >Don't think it has actual use. Moreover, no, it's not possible,
> >since the diffs are combined on merge, so the parts are not
> >there to be signed.
> 
> I very much want to know "where did this code come from",
> transitively.  Couldn't the signatures be stored in the working
> directory, so that on a merge this data could be logged?

The "arch-way" (my way, anyway (heh)) would involve having a local
mirror of the archive I'm merging from, so I can trivially check the
validity of the signature at any time.  Also, the commit of the merge
will include details of which changes were committed.  If someone else
wanted to verify if A and B's changes were applied by C with trojaning,
they can just repeat the merge (after verifying the sigs on A and B's
archive, personally) and (modulo conflicts) should get the same results.

-- 
Rob Weir <address@hidden> | address@hidden  |  Do I look like I want a CC?
Words of the day:  Aldergrove world domination Area 51 NORAD KGB PGP global NWO

signature.asc
Description: Digital signature