Re: CVS conflict avoidance

Re: CVS conflict avoidance

[Jason Merrill]

Here's what I do:  First I update the files from which other files are
generated, then I update the whole tree.

eup() { ( cd ~/eg
  find . -name configure.in -o -name '*.y' | xargs cvs update
  cvs update -P
); }

Jason

Re: CVS conflict avoidance

[H.J. Lu]

> 
> I wonder if it was possible to hack the CVS repository setup at cygnus
> such that *CVS* would regenerate `*-parse.c' (or similar) whenever
> somebody commits in a change to any of the relevant source files.  Sort of
> like how the files in CVSROOT are kept current.
> 
> I can see two potential flaws in this scheme: nothing guarantees that the
> generated file compiles correctly, and the corresponding file in my source
> tree would not reflect the version in the repository unless I would do
> `update' immediately after the commit.  Perhaps these two can be worked
> around?
> 

I have been using CVS to control my binutils for Linux.
I periodically import the gas snapshot into my CVS. But
I purposely leave out those generated .c/.h files as
well as *.info* from my CVS. One reason for me to do it
is what has been mentioned here. When I make my binutils
snapshots, I generate those files by hand. I wish Makefiles
in binutils can do that for me:

1. Add "make update-generated-files" which works
with both "make update-generated-files" and
"make update-generated-files -f Makefile.in".
2. "make gas.tar.gz -f Makefile.in" will do a
"make update-generated-files" before making the
tar ball.

The same thing can be said for egcs.


H.J.

Re: CVS conflict avoidance

[Stephen Williams]

robertl@dgii.com said:
> We have several files in EGCS that are generated from other files in
> EGCS.  These include pairs like configure.in and configure and
> *-parse.y and *-parse.c. 

It is my experience with CVS that generated files, including *-parse.c
and configure and whatever has a source version in CVS, should not ever
be included in the repository. Configure in particular can be generated
automatically by the cvs export process.

The difficulty in this case, however, is arguing over who has the right
version of autoconf/bison/flex/foobar. I suspect that you are using a
different version of autoconf anyhow, otherwise this problem would not
be appearing in the first place:-)

If egcs is very sensitive to the version of autoconf, then perhaps
autoconf needs to be included in cvs as well. If not, then who cares?
keep configure out of CVS! No?

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve@icarus.com              But I have promises to keep,
steve@picturel.com            and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re: CVS conflict avoidance

[Jean-Pierre Radley]

Mark Phillips telecommunicated (on 05Feb):
| 
| It may be a difficuly solution, but it sounds like it is CVS which is
| broken to me.....
| 
| I tend to think CVS should be preserving repositary (version) timestamp 
| on the destination file, if they are identical.

That really would be the best.  It's one of the reasons I prefer ncftp
over stock ftp, because it does preserve timestamps (and thus is
intelligent enough, if you do a recursive get, to fetch only what's
newer in the source machine compared to the target machine).

-- 
Jean-Pierre Radley <jpr@jpr.com>  XC/XT Custodian   Sysop, CompuServe SCOForum

Re: CVS conflict avoidance

[John Polstra]

In article < Pine.HPP.3.95q.980205104009.7139N-100000@bharh59a.europe.nortel.com >,
Mark Phillips  <M.S.Phillips@nortel.co.uk> wrote:

> I tend to think CVS should be preserving repositary (version) timestamp 
> on the destination file, if they are identical.
[...]
> Maybe this should be reported to the CVS maintainers as a bug?!

Don't bother -- this is the intended behavior.  I saw it discussed in
the CVS FAQ.  The rationale is as follows.  Suppose that CVS behaved
as you propose.  Now the following time line of events occurs:

    January 1	You check out the sources with "cvs co", but don't
		compile them yet because you're too busy.

    January 2	Somebody commits some new changes to various files
    		in the CVS repository.

    January 3	You get a free moment during lunch, and compile your
    		checked-out sources.

    January 4	You update your sources with "cvs upd", and do
    		another "make".

In this scenario, your object files would have time stamps from
Jan. 3, but your updated files after the "cvs upd" would have time
stamps from Jan. 2.  Thus make wouldn't recompile your updated sources
as it should.

This is the reason that CVS syncs the timestamps only on an initial
checkout.  When merely updating an existing file, it allows the time
stamp to be set to "now".

CVS has plenty of warts.  But I think the implementors did the right
thing in this case.

(I had to learn all these gory details when I was developing CVSup.)

John
--
   John Polstra                                       jdp@polstra.com
   John D. Polstra & Co., Inc.                Seattle, Washington USA
   "Self-knowledge is always bad news."                 -- John Barth

Re: CVS conflict avoidance

[Ian Lance Taylor]

   Date: Thu, 5 Feb 1998 10:44:43 +0000 (GMT)
   From: Mark Phillips <M.S.Phillips@nortel.co.uk>

   I tend to think CVS should be preserving repositary (version) timestamp 
   on the destination file, if they are identical.

   That way parse.c would only get rebuilt if parse.y was editied in the
   repositary or locally. Of course if you hack parse.c then someone edits
   parse.y, you deserve to get bitten....

   Maybe this should be reported to the CVS maintainers as a bug?!

The repository timestamp is already preserved on the initial checkout.
However, an update should not preserve the repository timestamp.  That
would sometimes cause changed files to look old, so in some cases make
would not compute correct dependencies.

Jason Merrill once suggested that CVS arrange for an update to
preserve the same time stamp ordering that is found in the
repository.  This would also have to be done on a checkin.  I believe
this would normally fix the problem.

However, as one of the CVS maintainers, I suspect that reporting the
bug will not really accomplish anything.  Some interested person will
have to actually write the patch.

I personally find --enable-maintainer-mode quite usable in practice,
and automake is a precedent.

Ian

Re: CVS conflict avoidance

[Lassi A. Tuura]

I wonder if it was possible to hack the CVS repository setup at cygnus
such that *CVS* would regenerate `*-parse.c' (or similar) whenever
somebody commits in a change to any of the relevant source files.  Sort of
like how the files in CVSROOT are kept current.

I can see two potential flaws in this scheme: nothing guarantees that the
generated file compiles correctly, and the corresponding file in my source
tree would not reflect the version in the repository unless I would do
`update' immediately after the commit.  Perhaps these two can be worked
around?

//lat
--
Lassi.Tuura@cern.ch          There's no sunrise without a night

Re: CVS conflict avoidance

[Joseph H. Buehler]

Robert Lipe <robertl@dgii.com> writes:

> We have several files in EGCS that are generated from other files in 
> EGCS.  These include pairs like configure.in and configure and *-parse.y
> and *-parse.c.
> 
> If you are using remote CVS and don't have exactly the same version of
> autoconf or bison or byacc or whatever, the timestamp thing can sneak up
> on you.  For example, if we do an update and CVS ships is both parse.c
> and parse.y, CVS guarantees that they'll arrive alphabetically (sigh).
> So *this time*, make will regenerate parse.c from parse.y.  Now, say we

...

> Can anyone think of a better way to handle this?

How about renaming the files so alphabetical order is OK?

Joe Buehler

Re: CVS conflict avoidance

[Branko Cibej]

> I've now experimented with .cvsignore to try to make it ignore only the
> generated files or only the source files, but once files are explictly
> added to the repository (i.e. they appear in CVS/Entries) the .cvsignore
> doesn't seem to matter.

How about having a .cvswrappers entry for such files, e.g.,

     *-parse.c    -m COPY

so that such files aren't merged, but are simply overwritten?
The only problem I see with this is that cvswrappers are supposed to be
unreliable in a client/server setup, but I think the -m option should work.

    Brane

--
Branko Cibej   <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
phone: (++386 61) 186 53 49  fax: (++386 61) 186 52 70

Re: CVS conflict avoidance

[Richard Earnshaw]

>    Date: Wed, 4 Feb 1998 23:25:01 -0600
>    From: Robert Lipe <robertl@dgii.com>
> 
>    We have several files in EGCS that are generated from other files in 
>    EGCS.  These include pairs like configure.in and configure and *-parse.y
>    and *-parse.c.
> 
>    [This causes problems with CVS]
> 
> One approach is the --enable-maintainer-mode configure option used by
> automake.  We would arrange matters such that the dependencies of
> these files were only present if --enable-maintainer-mode was used.
> If that configuration option were not used, then configure would not
> depend upon configure.in, and c-parse.y would not depend upon
> c-parse.c.
> 
> In automake this is done by having --enable-maintainer-mode substitute
> MAINT as the empty string, while its absence substitutes MAINT as
> `#M#'.  Then rules are written as
>     configure: @MAINT@configure.in
>             autoconf
> So if you do not configure with --enable-maintainer-mode, configure is
> only rebuilt if it does not exist at all.
> 

I'd prefer to see only those files that can't be recreated in the CVS repository (ie nothing that gets removed by maintainer-clean should be in the repository).  OK, so people doing direct access would need to have a full set of maintainer tools installed, but anyone using this level of access is effectively a maintainer, so I don't see a problem with that.  Snapshots could still have the full set of distribution files.

Re: CVS conflict avoidance

[Mark Phillips]

It may be a difficuly solution, but it sounds like it is CVS which is
broken to me.....

I tend to think CVS should be preserving repositary (version) timestamp 
on the destination file, if they are identical.

That way parse.c would only get rebuilt if parse.y was editied in the
repositary or locally. Of course if you hack parse.c then someone edits
parse.y, you deserve to get bitten....

Maybe this should be reported to the CVS maintainers as a bug?!

Cheers
Mark



Mark S. Phillips        ESN 742 2461
msp@nortel.co.uk        Tel. +44 1279 402461

Re: CVS conflict avoidance

[Ian Lance Taylor]

   Date: Wed, 4 Feb 1998 23:25:01 -0600
   From: Robert Lipe <robertl@dgii.com>

   We have several files in EGCS that are generated from other files in 
   EGCS.  These include pairs like configure.in and configure and *-parse.y
   and *-parse.c.

   [This causes problems with CVS]

One approach is the --enable-maintainer-mode configure option used by
automake.  We would arrange matters such that the dependencies of
these files were only present if --enable-maintainer-mode was used.
If that configuration option were not used, then configure would not
depend upon configure.in, and c-parse.y would not depend upon
c-parse.c.

In automake this is done by having --enable-maintainer-mode substitute
MAINT as the empty string, while its absence substitutes MAINT as
`#M#'.  Then rules are written as
    configure: @MAINT@configure.in
            autoconf
So if you do not configure with --enable-maintainer-mode, configure is
only rebuilt if it does not exist at all.

Ian

CVS conflict avoidance

[Robert Lipe]

[ No, not the sort of conflict that's filling the gcc list. ] 


I've danced around this for a while, but a discussion with Jeff made
me start thinking about it harder.

We have several files in EGCS that are generated from other files in 
EGCS.  These include pairs like configure.in and configure and *-parse.y
and *-parse.c.

If you are using remote CVS and don't have exactly the same version of
autoconf or bison or byacc or whatever, the timestamp thing can sneak up
on you.  For example, if we do an update and CVS ships is both parse.c
and parse.y, CVS guarantees that they'll arrive alphabetically (sigh).
So *this time*, make will regenerate parse.c from parse.y.  Now, say we
have a slightly different bison than whoever is doing the master version
(this is more apparant in autoconf than in bison, but humor me) Now, the
next time we do an update, if it sees a reason to update only parse.c
(no, I don't understand why but it does happen) we're almost guaranteed
to have a conflict to resolve.  Of course, the easiest way to resolve
this conflict is to 'rm parse.c ; cvs update parse.c'.   Unfortunately,
I typically don't notice the conflict until the build that I just left
to run overnight unattended fails after about 10 minutes. 

This seems to be become a problem only when one half or the other of the
pair isn't updated and the other is and the generated file is generated
locally by slightly different tools than the tools used to generate the
one that's in the repository.  I could have the exact circumstances
wrong, but the punchline is that conflicts in configure and *-parse.c
files seem common.

I've now experimented with .cvsignore to try to make it ignore only the
generated files or only the source files, but once files are explictly
added to the repository (i.e. they appear in CVS/Entries) the .cvsignore
doesn't seem to matter.

I've thought about adding a top-level makefile target that touches
either the set of source files or the set of generated files depending
on whether you had m4, autoconf, bison, etc. or you wanted to just be in
"snapshot mode" and expect everything ready to run.  This seems pretty
kludgey.

Can anyone think of a better way to handle this?

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com