Hello Simon,
* Simon Josefsson wrote on Mon, Dec 04, 2006 at 11:20:56PM CET:
> Paul Eggert <[EMAIL PROTECTED]> writes:
>
> > While I'm throwing oil onto the fire, I have a similar opinion of the
> > version numbers we maintain in the .m4 files. They're even worse,
> > since they're maintained by
$ grep Id COPYING
$Id: COPYING,v 1.3 2006/10/26 16:20:28 eggert Exp $
Oh. I thought you were talking about the GPL "COPYING" file. I don't
think that top-level gnulib file should be named COPYING :). I don't
know if I was responsible for that one, but it seems unlikely Paul was
...
Jim Meyering <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> wrote:
>> Jim Meyering <[EMAIL PROTECTED]> writes:
>>> Does anyone object to my removing the $Id...$ strings from those files?
>>> They will serve no purpose once we migrate.
>>
>> I'd rather not remove them as long as
[EMAIL PROTECTED] (Karl Berry) wrote:
> Do you really care whether any of the following files (the only ones
> affected in gnulib) contain an CVS/RCS-style $Id...$ string?
>
>COPYING
>
> COPYING has no $Id$. What am I missing?
this?
$ grep Id COPYING
$Id: COPYING,v 1.3 2006/1
Paul Eggert <[EMAIL PROTECTED]> writes:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
>
>> I find these markers useful when comparing file dates when updating
>> old software, and I think it would be a clear disadvantage if moving
>> to git won't make the same thing possible.
>
> They are controve
Do you really care whether any of the following files (the only ones
affected in gnulib) contain an CVS/RCS-style $Id...$ string?
COPYING
COPYING has no $Id$. What am I missing?
config/srclist-update
config/srclist.txt
config/srclistvars.sh
doc/Makefile
doc/gnulib.
version numbers we maintain in the .m4 files. They're even worse,
They may be worse in the abstract, but I really hope we don't get rid of
them, ever (even aside from the aclocal question). They have proven
*extremely* useful to me in sorting out auto* problems.
karl
Paul Eggert wrote:
> Simon Josefsson <[EMAIL PROTECTED]> writes:
> > I find these markers useful when comparing file dates when updating
> > old software, and I think it would be a clear disadvantage if moving
> > to git won't make the same thing possible.
>
> They are controversial. I'd rather r
Simon Josefsson <[EMAIL PROTECTED]> wrote:
> Jim Meyering <[EMAIL PROTECTED]> writes:
>> Does anyone object to my removing the $Id...$ strings from those files?
>> They will serve no purpose once we migrate.
>
> I'd rather not remove them as long as we are using CVS as the master
> repository.
>
>
Hello Paul,
* Paul Eggert wrote on Mon, Dec 04, 2006 at 08:14:00PM CET:
>
> While I'm throwing oil onto the fire, I have a similar opinion of the
> version numbers we maintain in the .m4 files. They're even worse,
> since they're maintained by hand.
Except the serial numbers also have a technic
Simon Josefsson <[EMAIL PROTECTED]> writes:
> I find these markers useful when comparing file dates when updating
> old software, and I think it would be a clear disadvantage if moving
> to git won't make the same thing possible.
They are controversial. I'd rather remove them, at least in the fi
Am 04.12.2006 um 10:16 schrieb Paul Eggert:
From: Georg Schwarz <[EMAIL PROTECTED]>
Subject: Re: coreutils 6.6 fails to compile on IRIX 5.3
configure:20647: cc -c -g conftest.c >&5
cfe: Warning 807: conftest.c, line 185: member cannot be of
function
or incomple
te type.
Jim Meyering <[EMAIL PROTECTED]> writes:
> Does anyone object to my removing the $Id...$ strings from those files?
> They will serve no purpose once we migrate.
I'd rather not remove them as long as we are using CVS as the master
repository.
Once, or if, we make the switch to something else, we
So far, no one has objected to my proposal to convert gnulib development
from cvs to git. If there are any nay-sayers, it's time to speak up.
I've just gone through the conversion process once more, and
pushed the result to the usual place:
http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=summary
> From: Georg Schwarz <[EMAIL PROTECTED]>
> Subject: Re: coreutils 6.6 fails to compile on IRIX 5.3
> configure:20647: cc -c -g conftest.c >&5
> cfe: Warning 807: conftest.c, line 185: member cannot be of function
> or incomple
> te type.
>struct s { int n; double d[];
Thanks for the details.
For the record, I'm sending this to bug-gnulib, so others know, too.
From: Georg Schwarz <[EMAIL PROTECTED]>
Subject: Re: coreutils 6.6 fails to compile on IRIX 5.3
Date: Sun, 3 Dec 2006 23:31:31 +0100
To: Jim Meyering <[EMAIL PROTECTED]>
Am 03.12.2006 um 20:02 s
16 matches
Mail list logo
