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

[Miles Bader]

On Sun, Sep 28, 2003 at 12:12:49PM +0200, Andrea Arcangeli wrote:
> Sorry but I disagree here and that's the very reason the tag-id are
> metadata and they're not data, and they provide zero value to the
> project in the long run.

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?).

> Today swap_state.c is swap_state.c, tomorrow
> swap_state.c could be nvidia.c just because I did `move-tag swap_state.c
> nvidia.c`. then it's just worthless to rememeber that was swap_state.c.

Then _don't do that_.  If you create a _new file_, then give it a _new id_.
On the other hand, if you move a file somewhere, use the _same id_.  You can
certainly think up weird edge cases where it's not clear what to do, but that
doesn't really matter; 95% of the time, the `identity' of a file is an
entirely intuitive concept, across renames, content changes, whatever.

> Infact if something the tag-id should be a total random id and 'arch'
> should costantly audit for possible collisions since math doesn't
> guarantee safetly with the tagline (unlike explicit mode that can
> guarantee safety with my my-id+sequencenumber algorithm)

explicit ids and taglines are the same, the only difference is where the
actual id is stored; in both cases, arch makes sure that there are no
collisions.

> The very moment I run 'tag-move swap_state.c nvidia.c' it means I want
> to forget where that file came from in the data.  For me the old
> swap_state.c doesn't exist anymore, nobody should remind me where
> nvidia.c comes from when I read the source, that's pure confusion and
> worthless information in the source. That's nvidia.c now, it's a device
> driver. 

Why are you going on about this?  Even if you've done such a thing, it's a
weird unusual case.  How about instead using _common_ cases to reason about
what features are useful?

> The proof this is metadata, is that if you had any second channel in the
> inode where you could store your metadata (some other projects asked for
> this feature over time), you would be using it already instead of
> polluting the file (IMHO at least ;).

Actually, no, I'd still use taglines.  Why?  Because they _always_ stay with
the file, no matter where it goes, whether copied among many different
filesystems, transferred using ftp, stored in tar file, compressed,
cut-n-pasted in someone's mail message, _everywhere_.  Inode-meta-data, no
matter how handy in some cases will never equal this functionality (well no
time soon, anyway).

> Again, it may be fine in a smaller project so you can still avoid to run
> add-tag/delete-tag/move-tag, but in something huge I believe they should
> be discouraged.

No.  It's exactly in large projects where they are needed the most.

Really, as far as I can see, your only really defensible poitn is that you
think they're ugly.  That's your right, but don't be surprised when it fails
to move the rest of us, who know can see the _benefits_ of taglines as well
(and having actually _used_ them, know how utterly non-intrusive they are --
far better than most of the _other_ meta-data that gets stuck in linux source
files [and yes, there's a lot of it]).

-Miles
-- 
Love is a snowmobile racing across the tundra.  Suddenly it flips over,
pinning you underneath.  At night the ice weasels come.  --Nietzsche