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

[Tom Lord]

    > From: Andrea Arcangeli <address@hidden>

    > Sorry but I think tagline is the worst mode. I prefer it's unable to
    > merge, than to see a file called hello.c to have a comemnt me.c that
    > could stay there forever just because ages ago it was called me.c. How
    > ugly it is when you go read the code? Also I'm unsure what happens if
    > you move it across directories.

Heh.  `tagline' doesn't require that at all.... it's just what my
emacs template that generates tags happens to do for no particular
reason.

Whether or not `tagline' is good really depends on how you're used to
managing sources.   `tagline' does a pretty good (not perfect, but
pretty damn good) job of eliminating a need to ever run any revision
control commands just because you've moved files around.   So, for
example, you can use your favorite directory-editor/file-manager to
shuffle sources and you don't have to teach it to fork/exec tla
instead of using rename/unlink/rmdir(2).


    > you're still thinking at a small project methinks.

    > With the kernel there are tons of exceptions, somebody wrote a dontdiff
    > (writing the dontdiff is the very same problem of defining what is junk)
    > but it has to be maintained and it keeps breaking all the time, see my
    > last version (and I had to stop using it because it just keeps getting
    > garbage every once in a while so it forces me to check every diff).
    > Likely the below won't work for 2.5 for example. The kernel is a big
    > moving target.

It's funny.   Not something worth arguing over.

But from where I sit: _you're_ the one applying small project thinking
to a large project.

Imposing (gasp!) the horrifying discipline (shocking!) of `inventory'
would make the moral equivalent of `dontdiff' robust -- seems like a
good thing to do for a large tree in a busy project.

Somebody wants to add some new name in some part of the source or to
the things that might wind up in the source tree -- with an
`inventory' discipline, they have to think about it and make the
trade-offs up front.  Without that discipline, it's a free-for-all and
any contributor can add to the hair for everyone else.

Your observations about having to abandon `dontdiff' illustrate that
the process currently used is horked.

If anything, it'll be a good sign when people start saying things
like:  "Say, we can get a separate distribution that contains just
inventory, the tag management tools, mkpatch/dopatch, and the
to<->from email changeset tools?"

    [long list of dontdiff globs]

    > this has no way to scale, the above has to be part of arch too to work
    > distributed, it can't be a local knowledge because it changes remotely
    > too.

"The question is," said Humpty Dumpty, "who is to be master - that's all."

A little coding standard or two can answer that question with "nobody
in particular --- it's not an issue any more."


    [sample tagline tag]

    > how ugly can that be? It's a totally broken idea to put metadata mixed
    > with the data. Files are there to be nice to be read. we must not
    > pollute our eyes with metadata, 

You mean like copyright notices?   Really, just stick it at the bottom
of the file and you'll hardly notice it's there.


    > that's why all the metadata is in
    > {arch}, so an ls as well gets the less possible pollution. I also
    > dislike the metadata for emacs indentation at the end of the file.


I agree that minimizing these things is best.   But there are trade-offs.


    > sorry but I think the tagline is the very worst method. I'd sure prefer
    > names to tagline ;).


";)" means you're joking, right?   

arch can enhance the project with the liberty to reorganize sources in
a managable way.   To use `names' method is to decide that such
reorganization is not important.


    > It can work well in a small project where you all use arch, but with
    > linux and a moltitude of users using all sort of different tools the
    > data has to be clean, and the checkins have to be strict IMHO.

Well, allegedly BK can handle tree-deltas, right?   I think you might
want to consider what I suggested:  inventory, tags, and changeset
tools as something that can be factored out and used by users of any
(or no) revision control system.

Perhaps even if there's no likelihood of Linus using arch anytime
soon, he might nevertheless use `dopatch'.

-t