[Gnu-arch-users] Re: give us a hand with arch

[Miles Bader]

Andrea Arcangeli <address@hidden> writes:
> > Actually they provide quite a bit of value.  I have no idea, why you
> > seem so intent on moaning about them (are you afraid they _will_ get
> > used for linux?).
> 
> Can you answer a very simple question?
> 
> Tell me what advantages and disavantages I would have by adding tagline
> to all files, compared to explicit, with strict commits. If you find a
> single advantage I will add them.

Um, OK:  file identity persists through changes out of arch's control
(a very real issue with the kernel, BTW).

> Problem is you can't because there aren't.  There are only
> disavantages, this is a tangible fact.

Er, no it's your opinion (I mean, do you think those of using taglines
are hallucinating, or stupid, or what?).

> disavantages of taglines with strict commit enabled:
> 
> 1) lose the math guarantee of no clashes (which can instead be
>    easily provided with the explicit method)

Remember, that explicit tags and taglines _are for most purposes the
same_; the only difference is where the id is stored, in the source
file, or in a separate little file.

I suspect that you're right, and that there's a great chance of
`collisions' with taglines, because someone might copy a source file,
and attempt to commit it without changing the tagline.  To duplicate an
explicit id, you've got to be even more stupid. :-)

Nonetheless, there is no `mathematical guarantee' against explicit
clashes, so tla has to check for them regardless of which tagging method
you use (OK, I suppose not with "names").  Since tla does this check, it
will tell you when it happens, and you can fix it.

> 2) pollute the code

Your personal taste (and not shared by many, AFAICS).

There's nothing wrong with this, of course, but it _is_ a personal
thing, so it's not usually a very persuasive argument.

> 3) annoy your and my eyes with metadata

Your personal taste (and not shared by many, AFAICS).

> 4) having to bother choosing the tagline

I have a script that does this automatically (it also adds explicit
tags, BTW; I just always use this script for everything).

> 5) having to check over time that there is no clash in the local tree
>    (according to your email arch is already checking for this, that
>    means wasting some minor cpu time)

Yes: minor cpu time, completely overwhelmed by all the other stuff that
happens.  This is not an issue.

> 6) waste cpu time as well to regexp all the 500M of 2.6 kernel data
>    searching for those tags

What do you base _that_ calculation on?

For operations where arch needs tag information (basically, making
changesets, whether for commit or for what-changed), taglines and
explicit tags seem to require roughly comparable resources to find:

 (1) For the case where arch has cached inode-state information,
     it's not necessary to examine unmodified files to look at taglines
     (because that info is cached); theoretically the same is true of
     explicit tags, but apparently this optimization is not yet added,
     so in fact it's _more_ inefficient to use explicit tags in this case.

 (2) For the case where arch has no cached inode-state information (or
     none that's applicable), it much look for tags.  For taglines, this
     means reading the first- and last-1K of each file -- but of course
     you _already_ need to read the file in this case, because you've
     got to do a diff (remember, this is the case where you have no
     cached inode-state to avoid doing diffs).  For explicit tags, this
     means reading the little extra .id files to get the tag -- PLUS
     reading the actual files to do the diffs.  In this case, I'd say
     taglines probably require _less_ resources to read than explicit
     tags, as you're reading fewer files.

Conclusion: no wasted CPU time for taglines; indeed, taglines probably
save CPU time.

> 7) having to check over time that there is no clash with parallel trees
>    not yet synced that arch can't know about
> 
> advantages:
> 
> 0) None, I've to use strict commits so I can't avoid `tla
>    add/delete/move-tag`.

I've no idea what you mean by this; `strict commits' don't mean you must
do `tla add/delete/move-tag`.  They mean that files must have a
(non-name) tag to be committed.  The tag can come from either an
explicit tag (create with `tla add') or from a tagline.

> I hope this explains why tagline isn't going to ever hit the linux
> codebase.

No, it doesn't, for obvious reasons (see above).

> 2) you have to convince strict commits aren't the way to go but I'm
>    very convinced they _are_ the safer and best way to do revision
>    control.  Adding and moving files is sooo infrequent, that it's
>    perfectly acceptable to run `tla move-tag`, strict commits are a
>    feature not a disavantages.

I'm still confused by your apparent notion that strict commits are
somehow equivalent with requiring `tla move-tag' -- they don't.

> the thing will move over time, first fs/buffer.c, then a new dir
> fs/vfs could be created and it will be fs/vfs/vfs_buffers.c

Right, and in that case, the file just moved => keeping the same tag is good.

> then it gets splitted etc.

Right, in this case, you need to add a new tag for one of the new files.
tla will make sure you do this (because the pre-commit tree-lint will
fail, telling you have a duplicate tag).  Remember, this is a fairly
rare case -- it's much more common that files simply get moved around.

Note that this already happens with bitkeeper -- I've sent changes to
linus that essentially split a file into two new files.  I used a patch
file to send this change to Linus, and he used his BK tools to apply it,
and the result was: the old file was renamed to _one_ of the new files,
and the other new file was a `really new' file.  This makes sense, I
think.

> I'm quite sure in linux we can't maintain the huge regexp, that can't be
> updated in sync every time a new driver is being merged into mainline.

Huh?  I _already_ maintain such regexps for linux, not in arch, but in
my auxilarly `ignore these files for doing a patch/build-link/etc'
files.  It's not hard at all (I can't even remember the last time it was
necessary to update those).

> This is only a guess, I can't read Linus's brain ;), but that's at least
> my own opinion on the matter. Again I could be wrong, but I'd like you
> to answer to the disavantage/advantage list.

Sure.

-Miles
-- 
`The suburb is an obsolete and contradictory form of human settlement'