Re: [Bug-gnulib] $Id$

[Karl Berry]

    I too prefer to avoid use of $Id$.

Why?

    It wouldn't mean too much by itself anyhow, 

It would unambiguously identify the file (in any given place).  This is
useful when looking at the gnulib files per se.  Right now it's a matter
of looking it up in the cvs repository to see when the last change was.
Annoying.

    because once the addition made it into my coreutils repository, the
    numbers there would be sure to differ -- or maybe they'd even be the
    same while the files are the otherwise identical.

Yes, the $Id$ would differ even when the files were otherwise the same.
So what :)?  It's still a way to know what you've got.

    However, once things sync up enough, I'll have to find a way
    to make my coreutils stuff share the gnulib repository

This is why I wrote the little srclist-update script (for gnulib and
texinfo).   That is exactly what it does.  The paths will obviously be
different on other people's development machines, but the basic idea
should be ok.

    -- e.g., so that when I tag a coreutils release, it also tags the ,v
    files in gnulib.

My suggestion is not to even attempt to tag the ,v files in gnulib.
What's the win?  Instead, just have copies (kept up to date :) in
coreutils and tag those.  That keeps each source hierarchy possible to
check out in the usual way.  If you make coreutils developers check out
stuff from multiple hierarchies in order to get something coherent
... That way lies madness.  IMHO.