Re: [Bug-gnulib] $Id$

[Jim Meyering]

address@hidden (Karl Berry) wrote:
>     I too prefer to avoid use of $Id$.
>
> Why?

It complicates diffs and merges.

>     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

That sounds workable, but I find it useful to be able
to associate tags with revision numbers.  Much easier (than
unpacking a tarball) to determine which version of a file
a particular bug was fixed in.

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

Not what I meant.  I wouldn't ever do something so gross :-)

I was thinking of having the CVS modules on the same system
and making the lib/m4/config directories under coreutils (in
the repository) be symbolic links into the corresponding
gnulib directories.  That's how I kept the lib/, m4/, and doc/
directories in sync for fileutils, textutils, and sh-utils,
(before they all merged into coreutils) and it worked very well.