cvs problems ...

cvs problems ...

[Andreas Tobler]

Hi all,

am I the only one or do you see the same ?

cvs [update aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
Adjusting file timestamps
CVS update of full tree failed.


Thx,
Andreas

RE: cvs problems ...

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Andreas Tobler
> Sent: 08 October 2004 12:36
> To: gcc
> Subject: cvs problems ...
> 
> Hi all,
> 
> am I the only one or do you see the same ?
> 
> cvs [update aborted]: branch attribute does not match file 
> for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
> Adjusting file timestamps
> CVS update of full tree failed.

  Something similar just happened the other week, didn't it?

http://sources.redhat.com/ml/overseers/2004-q3/msg00118.html



    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: cvs problems ...

[Dave Korn]

[Overseers Cc'd in]

> -----Original Message-----
> From: gcc-owner On Behalf Of Dave Korn
> Sent: 08 October 2004 12:40

> > -----Original Message-----
> > From: gcc-owner On Behalf Of Andreas Tobler
> > Sent: 08 October 2004 12:36

> > Hi all,
> > 
> > am I the only one or do you see the same ?
> > 
> > cvs [update aborted]: branch attribute does not match file 
> > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
> > Adjusting file timestamps
> > CVS update of full tree failed.
> 
>   Something similar just happened the other week, didn't it?
> 
> http://sources.redhat.com/ml/overseers/2004-q3/msg00118.html


  Yes, it did.

http://www.google.com/search?q=NT_STATIC_THREADS_MAKEFILE+branch+attribute&h
l=en&lr=&filter=0

  ILT fixed it last time:
http://sources.redhat.com/ml/overseers/2004-q3/msg00116.html

  Or possibly Zack!
http://sources.redhat.com/ml/overseers/2004-q3/msg00113.html


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: cvs problems ...

[Andrew Haley]

Dave Korn writes:
 > 
 > [Overseers Cc'd in]
 > 
 > > -----Original Message-----
 > > From: gcc-owner On Behalf Of Dave Korn
 > > Sent: 08 October 2004 12:40
 > 
 > > > -----Original Message-----
 > > > From: gcc-owner On Behalf Of Andreas Tobler
 > > > Sent: 08 October 2004 12:36
 > 
 > > > Hi all,
 > > > 
 > > > am I the only one or do you see the same ?
 > > > 
 > > > cvs [update aborted]: branch attribute does not match file 
 > > > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
 > > > Adjusting file timestamps
 > > > CVS update of full tree failed.
 > > 
 > >   Something similar just happened the other week, didn't it?
 > > 
 > > http://sources.redhat.com/ml/overseers/2004-q3/msg00118.html
 > 
 > 
 >   Yes, it did.
 > 
 > http://www.google.com/search?q=NT_STATIC_THREADS_MAKEFILE+branch+attribute&h
 > l=en&lr=&filter=0

Ah, yes.

> The problem is related to checking in the file on a branch breaks
> the cvs server for some reason.

Oh dear.  I don't remember seeing this mentioned on gcc list, but
maybe it was.

This means every time someone does a merge to branch we'll lose the
server.

Andrew.

RE: cvs problems ...

[Dave Korn]

> -----Original Message-----
> From: Andrew Haley [mailto:aph@redhat.com] 
> Sent: 08 October 2004 13:10

> > The problem is related to checking in the file on a branch breaks
> > the cvs server for some reason.
> 
> Oh dear.  I don't remember seeing this mentioned on gcc list, but
> maybe it was.
> 
> This means every time someone does a merge to branch we'll lose the
> server.


  Oh look!  Ian Lance Taylor would _definitely_ be a good person to discuss
this with, considering he apparently wrote that error message in the first
place!

https://www.cvshome.org/dev/patches/meta

-------------------------snip!-------------------------
Date: Wed, 20 Jan 1999 03:09:36 -0500
From: Ian Lance Taylor 
To: bug-cvs
Subject: Re: TODO item 62 proposal

. . .

   A version of the Cygnus patch concerning separating out some metadata
   is at http://www.cyclic.com/cvs/dev-metadata.html ("simple form of
   separated metadata").

Here is a version of the patch against CVS 1.10.

Ian
-------------------------snip!-------------------------
+	if (STREQ (RCSBRANCH, key)
+	    && (value == NULL
+		? rdata->branch != NULL
+		: (rdata->branch == NULL
+		   || strncmp (value, rdata->branch,
+			       strlen (rdata->branch)) != 0)))
+	{
+	   error (1, 0, "branch attribute does not match file for `%s'",
+		  rcsfile);
+	}
-------------------------snip!-------------------------

  However considering his likely $TZ setting it might be a few hours yet
before he's available.

  Oh look, it happened again even more recently than the last one I found.

http://sources.redhat.com/ml/overseers/2004-q3/msg00166.html


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

RE: cvs problems ...

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Dave Korn
> Sent: 08 October 2004 13:55


  CGF says it should be fixed now:

http://sources.redhat.com/ml/overseers/2004-q4/msg00010.html

I don't currently have an up-to-date tree checked out, but you guys might
like to give it another go.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....
 

RE: cvs problems ...

[Diego Novillo]

On Fri, 2004-10-08 at 09:14, Dave Korn wrote:

> I don't currently have an up-to-date tree checked out, but you guys might
> like to give it another go.
> 
[ Adding overseers@ ]

Nope.  It's still hosed:

cvs checkout: Updating gcc/boehm-gc/doc
cvs [checkout aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/doc/simple_example.html,v'


Diego.

RE: cvs problems ...

[Andrew Haley]

Diego Novillo writes:
 > On Fri, 2004-10-08 at 09:14, Dave Korn wrote:
 > 
 > > I don't currently have an up-to-date tree checked out, but you guys might
 > > like to give it another go.
 > > 
 > [ Adding overseers@ ]
 > 
 > Nope.  It's still hosed:
 > 
 > cvs checkout: Updating gcc/boehm-gc/doc
 > cvs [checkout aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/doc/simple_example.html,v'

That is at least a different file, so whatever worked for
NT_STATIC_THREADS_MAKEFILE will presumably work again.

However did you manage to do merges from mainline to the SSA branch?

Andrew.

RE: cvs problems ...

[Diego Novillo]

On Fri, 2004-10-08 at 09:28, Andrew Haley wrote:

> However did you manage to do merges from mainline to the SSA branch?
> 
Yes.  I typically did 2-3 merges per month.  I'm also doing weekly
merges mainline->tree-cleanup-branch without incident.


Diego.

RE: cvs problems ...

[Andrew Haley]

Diego Novillo writes:
 > On Fri, 2004-10-08 at 09:28, Andrew Haley wrote:
 > 
 > > However did you manage to do merges from mainline to the SSA branch?
 > > 
 > Yes.  I typically did 2-3 merges per month.  I'm also doing weekly
 > merges mainline->tree-cleanup-branch without incident.

Hmm.  It's been a long time since we did a mainline->gcj ABI branch.
I wonder if the problem is that the commit list is too long for some
limit.

Andrew.

RE: cvs problems ...

[Andreas Tobler]

Seems to werk now,

thanks to those people who thanks belong to. I think cgf!

Andreas

Re: cvs problems ...

[Christopher Faylor]

On Fri, Oct 08, 2004 at 02:28:42PM +0100, Andrew Haley wrote:
>Diego Novillo writes:
> > On Fri, 2004-10-08 at 09:14, Dave Korn wrote:
> > 
> > > I don't currently have an up-to-date tree checked out, but you guys might
> > > like to give it another go.
> > > 
> > [ Adding overseers@ ]
> > 
> > Nope.  It's still hosed:
> > 
> > cvs checkout: Updating gcc/boehm-gc/doc
> > cvs [checkout aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/doc/simple_example.html,v'
>
>That is at least a different file, so whatever worked for
>NT_STATIC_THREADS_MAKEFILE will presumably work again.

Right.  Different directory.

Ok.  I have just zeroed every fileattr file in the gcc repository.

Maybe I should write a cron job to do that occasionally so that these
types of problems will be "fixed" eventually without human intervention.

At the expense of occasional slowdowns in cvs access, of course.

cgf

Re: cvs problems ...

[Andrew Haley]

Christopher Faylor writes:
 > On Fri, Oct 08, 2004 at 02:28:42PM +0100, Andrew Haley wrote:
 > >Diego Novillo writes:
 > > > On Fri, 2004-10-08 at 09:14, Dave Korn wrote:
 > > > 
 > > > > I don't currently have an up-to-date tree checked out, but you guys might
 > > > > like to give it another go.
 > > > > 
 > > > [ Adding overseers@ ]
 > > > 
 > > > Nope.  It's still hosed:
 > > > 
 > > > cvs checkout: Updating gcc/boehm-gc/doc
 > > > cvs [checkout aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/doc/simple_example.html,v'
 > >
 > >That is at least a different file, so whatever worked for
 > >NT_STATIC_THREADS_MAKEFILE will presumably work again.
 > 
 > Right.  Different directory.
 > 
 > Ok.  I have just zeroed every fileattr file in the gcc repository.
 > 
 > Maybe I should write a cron job to do that occasionally so that these
 > types of problems will be "fixed" eventually without human intervention.
 > 
 > At the expense of occasional slowdowns in cvs access, of course.

Well, I'd like to finish my checkin without breaking things.  Working
on the theory that CVS doesn't like big checkins, I'll do
per-directory checkins on my branch.

Andrew.

Re: cvs problems ...

[Christopher Faylor]

On Fri, Oct 08, 2004 at 02:54:28PM +0100, Andrew Haley wrote:
>Christopher Faylor writes:
> > On Fri, Oct 08, 2004 at 02:28:42PM +0100, Andrew Haley wrote:
> > >Diego Novillo writes:
> > > > On Fri, 2004-10-08 at 09:14, Dave Korn wrote:
> > > > 
> > > > > I don't currently have an up-to-date tree checked out, but you guys might
> > > > > like to give it another go.
> > > > > 
> > > > [ Adding overseers@ ]
> > > > 
> > > > Nope.  It's still hosed:
> > > > 
> > > > cvs checkout: Updating gcc/boehm-gc/doc
> > > > cvs [checkout aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/doc/simple_example.html,v'
> > >
> > >That is at least a different file, so whatever worked for
> > >NT_STATIC_THREADS_MAKEFILE will presumably work again.
> > 
> > Right.  Different directory.
> > 
> > Ok.  I have just zeroed every fileattr file in the gcc repository.
> > 
> > Maybe I should write a cron job to do that occasionally so that these
> > types of problems will be "fixed" eventually without human intervention.
> > 
> > At the expense of occasional slowdowns in cvs access, of course.
>
>Well, I'd like to finish my checkin without breaking things.  Working
>on the theory that CVS doesn't like big checkins, I'll do
>per-directory checkins on my branch.

I don't think that CVS should care about big checkins.  It's aborted
operations (checkin or possibly even checkout) which can cause problems.

cgf

RE: cvs problems ...

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Christopher Faylor
> Sent: 08 October 2004 14:57

> I don't think that CVS should care about big checkins.  It's aborted
> operations (checkin or possibly even checkout) which can 
> cause problems.

  Ah.  Of course (re my last post), loginfo probably doesn't run when
there's an aborted checkin.

  OTOH, you could abuse commitinfo to provide a pseudo-module name somewhere
that anyone with write access could queue a commit to, and then commitinfo
could trigger the job to fix the problem and then deny the commit.  That
would allow anyone with write access to CVS to trigger off the fix remotely.

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: cvs problems ...

[Diego Novillo]

On Fri, 2004-10-08 at 09:48, Christopher Faylor wrote:

> Ok.  I have just zeroed every fileattr file in the gcc repository.
> 
Thanks.

> Maybe I should write a cron job to do that occasionally so that these
> types of problems will be "fixed" eventually without human intervention.
> 
Sounds like a convenient workaround.  Does anyone know what the actual
bug is?  Any chance that this is being fixed in newer versions of CVS?


Diego.

Re: cvs problems ...

[Christopher Faylor]

On Fri, Oct 08, 2004 at 09:55:44AM -0400, Diego Novillo wrote:
>On Fri, 2004-10-08 at 09:48, Christopher Faylor wrote:
>>Ok.  I have just zeroed every fileattr file in the gcc repository.
>>
>Thanks.
>
>>Maybe I should write a cron job to do that occasionally so that these
>>types of problems will be "fixed" eventually without human
>>intervention.
>>
>Sounds like a convenient workaround.  Does anyone know what the actual
>bug is?  Any chance that this is being fixed in newer versions of CVS?

The bug is caused by the special mods that we have in CVS which speed up
operations on the trunk.  A separate "cache" (called fileattr) file is
created which contains version information for all files in a directory.
In certain pathological conditions, this file can occasionally become
out of date wrt to the files it references.

This patch isn't in standard CVS and, IIRC, has been rejected in the
past.  It needs more work before it would be accepted (it probably needs
to work on branches and it shouldn't be having the types of problems
that it has now) and I don't think anyone is interested in spending the
time to get it into shape for submission.

The speedup from this patch is dramatic, so for projects like gcc, I
think it makes sense to keep using it, even given the occasional
glitches.

cgf

Re: cvs problems ...

[Diego Novillo]

Sorry Chris, but CVS is _still_ hosed.  I just got this trying to
check-out a clean copy of tree-cleanup-branch:

cvs checkout: Updating gcc/libjava/java/io
cvs checkout: Updating gcc/libjava/java/lang
cvs [checkout aborted]: head attribute does not match file for `/cvs/gcc/gcc/libjava/java/lang/ieeefp.h,v'

'cvs up' does seem to work, though.  Perhaps because it didn't have to
go through that file.


Diego.

Re: cvs problems ...

[Christopher Faylor]

On Fri, Oct 08, 2004 at 10:11:45AM -0400, Diego Novillo wrote:
>Sorry Chris, but CVS is _still_ hosed.  I just got this trying to
>check-out a clean copy of tree-cleanup-branch:
>
>cvs checkout: Updating gcc/libjava/java/io
>cvs checkout: Updating gcc/libjava/java/lang
>cvs [checkout aborted]: head attribute does not match file for `/cvs/gcc/gcc/libjava/java/lang/ieeefp.h,v'
>
>'cvs up' does seem to work, though.  Perhaps because it didn't have to
>go through that file.
>
Reply-To: 
In-Reply-To: <1097244705.21858.30.camel@localhost.localdomain>

On Fri, Oct 08, 2004 at 10:11:45AM -0400, Diego Novillo wrote:
>Sorry Chris, but CVS is _still_ hosed.  I just got this trying to
>check-out a clean copy of tree-cleanup-branch:
>
>cvs checkout: Updating gcc/libjava/java/io
>cvs checkout: Updating gcc/libjava/java/lang
>cvs [checkout aborted]: head attribute does not match file for `/cvs/gcc/gcc/libjava/java/lang/ieeefp.h,v'
>
>'cvs up' does seem to work, though.  Perhaps because it didn't have to
>go through that file.

Well, this has been a fun morning.  :-)

I've re-wiped out the fileattr file in this directory and confirmed that
you can now check things out.  I suspect that there is a bug in CVS
somewhere which causes this problem when a file only exists on a branch.
So this problem may resurface.  If it persists, I'll link fileattr to
/dev/null.

Now, I can go back to trying to squash the multiple idiots who are
trying to download the whole site by making 500 simultaneous connections
to the web server...

cgf

Re: cvs problems ...

[Paolo Bonzini]

> The problem is that at the time the problem is discovered, CVS has
> already made the wrong decisions.
> 
> It would in principle be possible for CVS to restart the operation.

Or, clear the fileattr before stopping.  Maybe in the whole repo.

> Also there is evidently a bug in updating the fileattrs file when
> doing some sort of import operation.  I or somebody should look into
> that.

Hm, yes. :-(

Paolo

Re: cvs problems ...

[Mike Stump]

On Friday, October 8, 2004, at 07:00  AM, Christopher Faylor wrote:
> The bug is caused by the special mods that we have in CVS which speed 
> up
> operations on the trunk.

I'm wondering if Ian can come up with a way to remove the related cache 
file when the server hits the error message.  :-)  Then, one would only 
have to retry the operation, at most once for each cache that has been 
hosed.

RE: cvs problems ...

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Christopher Faylor
> Sent: 08 October 2004 14:49

> On Fri, Oct 08, 2004 at 02:28:42PM +0100, Andrew Haley wrote:

> >That is at least a different file, so whatever worked for
> >NT_STATIC_THREADS_MAKEFILE will presumably work again.
> 
> Right.  Different directory.
> 
> Ok.  I have just zeroed every fileattr file in the gcc repository.
> 
> Maybe I should write a cron job to do that occasionally so that these
> types of problems will be "fixed" eventually without human 
> intervention.
> 
> At the expense of occasional slowdowns in cvs access, of course.

  Since it's trigged by checkins, wouldn't it be ideal for one of those
"runs on the server every time you commit" cvs server scripts ?  

  Ah, yes, "Node: commit files" in "info cvs" suggests that "loginfo" would
be the place to put such a job.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: cvs problems ...

[Christopher Faylor]

On Fri, Oct 08, 2004 at 02:57:19PM +0100, Dave Korn wrote:
>> -----Original Message-----
>> From: gcc-owner On Behalf Of Christopher Faylor
>> Sent: 08 October 2004 14:49
>
>> On Fri, Oct 08, 2004 at 02:28:42PM +0100, Andrew Haley wrote:
>
>> >That is at least a different file, so whatever worked for
>> >NT_STATIC_THREADS_MAKEFILE will presumably work again.
>> 
>> Right.  Different directory.
>> 
>> Ok.  I have just zeroed every fileattr file in the gcc repository.
>> 
>> Maybe I should write a cron job to do that occasionally so that these
>> types of problems will be "fixed" eventually without human 
>> intervention.
>> 
>> At the expense of occasional slowdowns in cvs access, of course.
>
>  Since it's trigged by checkins, wouldn't it be ideal for one of those
>"runs on the server every time you commit" cvs server scripts ?  

It's triggered by any cvs operation but, typically, the only thing that
modifies this file is an operation that writes to the repository.  The
file can be written on checkout, though, if, for instance, someone had
gone in and zeroed it previously.

In any event, it's the aborted checkins which are the problems.  So I don't
think you could rely on cvs post-processing to do this job.

cgf

Re: cvs problems ...

[Zack Weinberg]

Christopher Faylor <me@cgf.cx> writes:

> On Fri, Oct 08, 2004 at 02:28:42PM +0100, Andrew Haley wrote:
>>Diego Novillo writes:
>> > On Fri, 2004-10-08 at 09:14, Dave Korn wrote:
>> > 
>> > > I don't currently have an up-to-date tree checked out, but you guys might
>> > > like to give it another go.
>> > > 
>> > [ Adding overseers@ ]
>> > 
>> > Nope.  It's still hosed:
>> > 
>> > cvs checkout: Updating gcc/boehm-gc/doc
>> > cvs [checkout aborted]: branch attribute does not match file for `/cvs/gcc/gcc/boehm-gc/doc/simple_example.html,v'
>>
>>That is at least a different file, so whatever worked for
>>NT_STATIC_THREADS_MAKEFILE will presumably work again.
>
> Right.  Different directory.
>
> Ok.  I have just zeroed every fileattr file in the gcc repository.

This particular recurrent failure seems to only stomp the fileattr
files below boehm-gc/.  Just so you know for next time.

zw

RE: cvs problems ...

[Andrew Haley]

Dave Korn writes:
 > > -----Original Message-----
 > > From: gcc-owner On Behalf Of Andreas Tobler
 > > Sent: 08 October 2004 12:36
 > > To: gcc
 > > Subject: cvs problems ...
 > > 
 > > Hi all,
 > > 
 > > am I the only one or do you see the same ?
 > > 
 > > cvs [update aborted]: branch attribute does not match file 
 > > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
 > > Adjusting file timestamps
 > > CVS update of full tree failed.
 > 
 >   Something similar just happened the other week, didn't it?
 > 
 > http://sources.redhat.com/ml/overseers/2004-q3/msg00118.html

I had a cvs commit crash at my end.  It might have corrupted the
repository.

Andrew.

RE: cvs problems ...

[Andrew Haley]

Andrew Haley writes:
 > Dave Korn writes:
 >  > > -----Original Message-----
 >  > > From: gcc-owner On Behalf Of Andreas Tobler
 >  > > Sent: 08 October 2004 12:36
 >  > > To: gcc
 >  > > Subject: cvs problems ...
 >  > > 
 >  > > Hi all,
 >  > > 
 >  > > am I the only one or do you see the same ?
 >  > > 
 >  > > cvs [update aborted]: branch attribute does not match file 
 >  > > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
 >  > > Adjusting file timestamps
 >  > > CVS update of full tree failed.
 >  > 
 >  >   Something similar just happened the other week, didn't it?
 >  > 
 >  > http://sources.redhat.com/ml/overseers/2004-q3/msg00118.html
 > 
 > I had a cvs commit crash at my end.  It might have corrupted the
 > repository.

Actually, I don't know the crash was at my end: it might have been the
server that crashed.

Andrew.

Re: cvs problems ...

[Phil Edwards]

On Fri, Oct 08, 2004 at 12:56:06PM +0100, Andrew Haley wrote:
>  > 
>  > I had a cvs commit crash at my end.  It might have corrupted the
>  > repository.
> 
> Actually, I don't know the crash was at my end: it might have been the
> server that crashed.

Either way, an interrupted commit will definitely corrupt the cache.
(And it is just a cache, specially modified for sources.redhat.com, that
gets corrupted.  Not the actual repository.  *whew*)

Fortunately, it's easy to clean up.


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: cvs problems ...

[Andrew Haley]

Phil Edwards writes:
 > On Fri, Oct 08, 2004 at 12:56:06PM +0100, Andrew Haley wrote:
 > >  > 
 > >  > I had a cvs commit crash at my end.  It might have corrupted the
 > >  > repository.
 > > 
 > > Actually, I don't know the crash was at my end: it might have been the
 > > server that crashed.
 > 
 > Either way, an interrupted commit will definitely corrupt the cache.
 > (And it is just a cache, specially modified for sources.redhat.com, that
 > gets corrupted.  Not the actual repository.  *whew*)
 > 
 > Fortunately, it's easy to clean up.

Scared the crap out of me.

Andrew.

Re: cvs problems ...

[Zack Weinberg]

Since it doesn't look like a fix for the underlying bug is coming in
short order, I'd like to suggest a custom for ensuring that the
repository gets restored to a usable state as fast as possible.

Whenever anyone does a merge of any kind, or hits ^C on a commit
operation, they should IMMEDIATELY AFTERWARD perform a cvs update from
a separate checkout of the trunk.  If this fails, they should
immediately notify overseers@sources.redhat.com, giving the full text
of the error message.  They should also mention the problem on the IRC
channel #gcc on irc.oftc.net, if possible.  (I do not want to force
people to use IRC if they aren't already familiar with it.  However,
that channel may well be a faster way to raise someone who knows how
to fix the problem.)

In other words, it is the responsibility of the person who did the
operation that might break CVS to find out if they broke CVS, and if
so, to notify someone who can fix it.

----

Fixing CVS requires shell access to gcc.gnu.org/sources.redhat.com and
write privileges on the repository that's busted.  I will outline what
one does, but caution everyone that this is fiddly and somewhat
dangerous - if you're not confident that you will not clobber the
wrong files, please leave it to the sysadmins.

The error message indicates the directory with a broken fileattr
cache, e.g.

> > cvs [update aborted]: branch attribute does not match file 
> > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'

The specific ,v file is irrelevant - it's just the first file that CVS
tried to access in the directory with the bad cache.  What you do when
you see this is

sourceware $ cd /cvs/gcc/gcc/boehm-gc
sourceware $ : > CVS/fileattr

The effect of that odd all-punctuation command is to truncate the file
to length zero, but leave its inode untouched.  This is important,
because the file has to be owned by the 'anoncvs' user.  If you delete
it, it will get recreated by the next person to access the repository,
with the wrong ownership.  [In case you would be more comfortable with
a longer but less cryptic command, "cp /dev/null CVS/fileattr" also
works.]

Then you immediately try to do a cvs update again.  Odds are that
it will throw the same error with a different pathname.  Truncate that
directory's CVS/fileattr too.  Repeat until the update succeeds.

zw

RE: cvs problems ...

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Zack Weinberg
> Sent: 08 October 2004 21:26

> Since it doesn't look like a fix for the underlying bug is coming in
> short order, I'd like to suggest a custom for ensuring that the
> repository gets restored to a usable state as fast as possible.
> 
> Whenever anyone does a merge of any kind, or hits ^C on a commit
> operation, they should IMMEDIATELY AFTERWARD perform a cvs update from
> a separate checkout of the trunk.  If this fails, they should
> immediately notify overseers

  Think that's a good idea.  In fact, it's always a good idea to do an
update after a commit, and preferably a rebuild (and even re-test) if
possible, since CVS commits aren't atomic and there's always the danger of
some kind of collision.  It's good to verify that what ended up in the
repository actually matches what you were trying to put in there!

> Fixing CVS requires shell access to gcc.gnu.org/sources.redhat.com and
> write privileges on the repository that's busted.  I will outline what
> one does, but caution everyone that this is fiddly and somewhat
> dangerous - if you're not confident that you will not clobber the
> wrong files, please leave it to the sysadmins.

  I think this could be a good job for a bot/script:

> The error message indicates the directory with a broken fileattr
> cache, e.g.
> 
> > > cvs [update aborted]: branch attribute does not match file 
> > > for `/cvs/gcc/gcc/boehm-gc/NT_STATIC_THREADS_MAKEFILE,v'
> 
> The specific ,v file is irrelevant - it's just the first file that CVS
> tried to access in the directory with the bad cache.  What you do when
> you see this is
> 
> sourceware $ cd /cvs/gcc/gcc/boehm-gc
> sourceware $ : > CVS/fileattr

  How about setting up a script, and a mail-alias that forwards to it, so
that anyone who gets one of those error messages can email it in, and the
script will parse out the directory path and fix up the fileattr
automagically?  [Naturally there are security issues to consider, but it
should be entirely possible to do in a robust fashion].

    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

cvs problems?

[Andreas Tobler]

cvs -z9 -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co gcc

cannot close CVS/Entries
No space left on device

It's not my device.
/dev/disk0s13  5073368  1151748  3667952    23%    /Volumes/xufs

Thanks,
Andreas

Re: cvs problems?

[Nathan Sidwell]

Andreas Tobler wrote:
> cvs -z9 -d :pserver:anoncvs@gcc.gnu.org:/cvs/gcc co gcc
> 
> cannot close CVS/Entries
> No space left on device
> 
> It's not my device.
> /dev/disk0s13  5073368  1151748  3667952    23%    /Volumes/xufs
I just got that too, a later checkout worked ok though, but I suspect
gcc.gnu.org is a bit ill

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org