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

[Robin Farine]

>>>>> "Andrea" == Andrea Arcangeli <address@hidden> writes:

    Andrea> On Fri, Sep 26, 2003 at 07:04:25PM -0700, Tom Lord wrote:
    >> 
    >> 
    >> > From: Andrea Arcangeli <address@hidden>
    >> 
    >> > There is no way I can maintain an huge regexp.
    >> 
    >> Want some advice?
    >> 
    >> Stop.  
    >> 
    >> Slow down.
    >> 
    >> Stop posting so much.

:-)

[...]


    Andrea> 1) the commit has to be strict for the kernel usage. You
    Andrea> simply can't pretend that we must allow a regexp to catch
    Andrea> statically all the junk forever, that's not feasible as I
    Andrea> stated in the quote above. I feel like you're disappointed
    Andrea> that we need this feature but I don't think it's fixable
    Andrea> by hoping everybody does the right thing. The need for the
    Andrea> strict commit is exactly to allow people to easily find
    Andrea> when they do a mistake and they left garbage in the tree:
    Andrea> to do the right thing before doing a commit.

Just build out of the source tree. Two solutions: (1) clone the tree
while using symlinks to files (works great with 2.4 and 2.6); (2) use
the build system patch that allows just that (but I think it's not an
option since it's for 2.5/2.6 only, right?).

[...]


    Andrea> 3) The third issue in my scale of priority (and this isn't
    Andrea> in the showstopper area anymore) is the tagging mode.

    Andrea> Since I need the strict commit in the first place, I
    Andrea> shouldn't be supposed to know or care about the tagging
    Andrea> mode at all when I'm in strict commit mode. To provide the
    Andrea> strict commit feature, obviously I have to tell arch every
    Andrea> time I move stuff around and as usual when I add or remove
    Andrea> stuff from the tree. Since I've to do that anyways for the
    Andrea> strict commit behaviour, then it'd be very wasteful for me
    Andrea> to be asked to manage the tagging in a non transparent
    Andrea> manner like it happens right now.

No, you don't have to tell arch. With any but the 'names' method, you
can customize how arch will classify a file that doesn't have a tag
(embedded or external), look for 'untagged-source' in the mailing-list
archive or in the =tagging-method generated by 'tla init-tree' (you
need a recent enough tla-1.1 revision).

Moreover, the neat thing with 'tagline' (or its more general
successor) is that the file unique identifier (i.e. tag) does not live
in the limited universe of a specific version control system. It
belongs to the file and travel with it. For example, if someone works
with CVS and maintains a tree forked from yours, you'll be able to
track the rename operations he did in his tree when you merge back
from it. And I am pretty sure that other SCM systems or even other
kind of applications could also benefit from this additional bit of
information.

The fact that it pollutes the body of the file is due to the way we
currently implement file storage. Let's consider a file system as a
mapping of names to objects, and these objects as sequences of bytes
split in two parts, meta-data in a standard format specifying -- among
other things -- the format/encoding of the body, followed by the body.
In such a world, I would like to stick a unique identifier for this
object in the object's meta-data rather than in a separate 'collection
of ids' object. In the current world, I just find much more useful to
add a single line containing a uuid at the end of a source file than
anything else.

[...]

    Andrea> The arch-tag for a file would be address@hidden where
    Andrea> 1234 is a sequence number per-project. It'll never be
    Andrea> decreased and it can grow to infinite (well a 64bit long
    Andrea> long would be more than enough, in practice even a long
    Andrea> would be ok ;).

Well, you probably mean UUIDs. I learnt from this list that GNU/Linux
systems have an alternative to 'uuidgen',
"/proc/sys/kernel/random/uuid", which provides exactly what we need.

-- 
rnf