Re: svn access on RHEL 4.0
On Jan 8, 2006, at 7:19 PM, Daniel Berlin wrote: On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote: OK, here are some details. Our server is a dual UltraSparc running Solaris 10 attached to the SAN. Working client situation: subversion 1.3.0 on Sparc Solaris 9, not using Berkeley DB Non-working client situation: subversion 1.3.0 on x86-64 RHEL 4.0, using Berkeley DB I think everything is running NFSv4 at this point. Unless you are running a server locally, whether you've compiled in BDB or not doesn't matter. Thank you all for your suggestions. I think we've isolated the problem enough to hand it off to someone else, since we have hardware and OS software support on all the machines involved. File server: dual ultrasparc running Solaris 10, serves the file system using either NFSv3 or NFSv4. Operation: svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc; cd gcc; contrib/ gcc_update Results: File system mounted as NFSv3 or NFSv4 on dual ultrasparc running Solaris 9: works File system mounted as NFSv3 on RHEL 4: works File system mounted as NFSv4 on RHEL 4: reports seeming file system corruption. This is reproducible, so perhaps someone can find a fix for it. Thanks again. Brad
Re: svn access on RHEL 4.0
On Sun, 2006-01-08 at 18:05 -0600, Bradley Lucier wrote: > On Jan 8, 2006, at 9:12 AM, Daniel Berlin wrote: > > >> > >> Try removing the offending directory (gcc/testsuite/gcc.dg/ > >> special) and > >> run svn cleanup again, updating the tree afterwards. If you > >> didn't have > >> any local changes in that directory you should not lose anything. > >> If the > >> problem persists then you probably have a hardware problem. > > > > Just "for the record": > > > > gcc.gnu.org runs RHEL4, and we've never had any trouble like this. > > > > All the snapshots are generated locally using svn, etc. > > OK, here are some details. Our server is a dual UltraSparc running > Solaris 10 attached to the SAN. > > Working client situation: subversion 1.3.0 on Sparc Solaris 9, not > using Berkeley DB > > Non-working client situation: subversion 1.3.0 on x86-64 RHEL 4.0, > using Berkeley DB > > I think everything is running NFSv4 at this point. Unless you are running a server locally, whether you've compiled in BDB or not doesn't matter.
Re: svn access on RHEL 4.0
On Jan 8, 2006, at 9:12 AM, Daniel Berlin wrote: Try removing the offending directory (gcc/testsuite/gcc.dg/ special) and run svn cleanup again, updating the tree afterwards. If you didn't have any local changes in that directory you should not lose anything. If the problem persists then you probably have a hardware problem. Just "for the record": gcc.gnu.org runs RHEL4, and we've never had any trouble like this. All the snapshots are generated locally using svn, etc. OK, here are some details. Our server is a dual UltraSparc running Solaris 10 attached to the SAN. Working client situation: subversion 1.3.0 on Sparc Solaris 9, not using Berkeley DB Non-working client situation: subversion 1.3.0 on x86-64 RHEL 4.0, using Berkeley DB I think everything is running NFSv4 at this point. So I don't know if the problem is with RHEL versus Solaris 10, or Berkeley DB versus non-Berkeley DB (whatever subversion uses when Berkeley DB is not available). Perhaps I can do some experiments to see whether Solaris 9 + Berkeley DB works or not. Brad
Re: svn access on RHEL 4.0
On Jan 8, 2006, at 9:04 AM, Andreas Schwab wrote: Try removing the offending directory (gcc/testsuite/gcc.dg/special) and run svn cleanup again, updating the tree afterwards. If you didn't have any local changes in that directory you should not lose anything. If the problem persists then you probably have a hardware problem. Thanks for I installed subversion 1.3.0 and tried your suggestion recursively and seemed to get into a cycle ---after removing libjava/testsuite/ libjava.lang as one of the "problem" directories on the way to getting a clean "xvn cleanup", it showed up again as one of the "problem" directories in trying to do contrib/gcc_update, notes are below. Actually, gcc_update appears to complain about libstdc++-v3/ testsuite/data immediately after installing a new version. (I got a slightly more detailed error message with 1.3.0 than with the default 1.1.4: euler-5% svn cleanup svn: XML parser failed in 'gcc/testsuite/gcc.dg/pch' svn: Bogus date but I don't know what "Bogus date" means in any detail.) It's interesting that you mention a possible hardware problem. The file system is mounted on a new SAN served from a Sparc NFSv4 server; do you thin that perhaps we should try to mount it using NFSv3 to see if that fixes the problem? Brad euler-36% tcsh euler-1% set path=(/export/users/lucier/local/subversion-1.3.0/bin/ $path) euler-2% which svn /export/users/lucier/local/subversion-1.3.0/bin//svn euler-3% dirs ~/programs/subversion-1.3.0 euler-4% pu ~/programs/gcc/4.2/ ~/programs/gcc/4.2 ~/programs/subversion-1.3.0 euler-5% svn cleanup svn: XML parser failed in 'gcc/testsuite/gcc.dg/pch' svn: Bogus date euler-6% /bin/rm -rf gcc/testsuite/gcc.dg/pch euler-7% svn cleanup svn: XML parser failed in 'libstdc++-v3/testsuite/data' svn: Bogus date euler-8% /bin/rm -rf libstdc++-v3/testsuite/data euler-9% svn cleanup svn: XML parser failed in 'libjava/classpath/org/omg/SendingContext' svn: Bogus date euler-10% /bin/rm -rf libjava/classpath/org/omg/SendingContext euler-11% svn cleanup svn: XML parser failed in 'libjava/testsuite/libjava.special' svn: Bogus date euler-12% /bin/rm -rf libjava/testsuite/libjava.special euler-13% svn cleanup svn: XML parser failed in 'libjava/testsuite/libjava.lang' svn: Bogus date euler-14% /bin/rm -rf libjava/testsuite/libjava.lang euler-15% svn cleanup svn: XML parser failed in 'libjava/testsuite/libjava.loader' svn: Bogus date euler-16% /bin/rm -rf libjava/testsuite/libjava.loader euler-17% svn cleanup euler-18% contrib/gcc_update Updating SVN tree Agcc/testsuite/gcc.dg/special Agcc/testsuite/gcc.dg/special/2419-2.c Agcc/testsuite/gcc.dg/special/wkali-1.c Agcc/testsuite/gcc.dg/special/wkali-2.c Agcc/testsuite/gcc.dg/special/wkali-2a.c Agcc/testsuite/gcc.dg/special/wkali-2b.c Agcc/testsuite/gcc.dg/special/mips-abi.exp Agcc/testsuite/gcc.dg/special/mips-abi.s Agcc/testsuite/gcc.dg/special/gcsec-1.c Agcc/testsuite/gcc.dg/special/weak-1.c Agcc/testsuite/gcc.dg/special/weak-2.c Agcc/testsuite/gcc.dg/special/weak-1a.c Agcc/testsuite/gcc.dg/special/weak-2a.c Agcc/testsuite/gcc.dg/special/alias-1.c Agcc/testsuite/gcc.dg/special/weak-2b.c Agcc/testsuite/gcc.dg/special/alias-2.c Agcc/testsuite/gcc.dg/special/special.exp Agcc/testsuite/gcc.dg/pch Agcc/testsuite/gcc.dg/pch/valid-1b.c Agcc/testsuite/gcc.dg/pch/macro-2.c Agcc/testsuite/gcc.dg/pch/decl-5.hs Agcc/testsuite/gcc.dg/pch/macro-4.c Agcc/testsuite/gcc.dg/pch/decl-1.c Agcc/testsuite/gcc.dg/pch/inline-3.hs Agcc/testsuite/gcc.dg/pch/decl-3.c Agcc/testsuite/gcc.dg/pch/import-1.c Agcc/testsuite/gcc.dg/pch/decl-5.c Agcc/testsuite/gcc.dg/pch/cpp-2.hs Agcc/testsuite/gcc.dg/pch/save-temps-1.hs Agcc/testsuite/gcc.dg/pch/static-2.hs Agcc/testsuite/gcc.dg/pch/import-1b.h Agcc/testsuite/gcc.dg/pch/cpp-2.c Agcc/testsuite/gcc.dg/pch/system-1.c Agcc/testsuite/gcc.dg/pch/pch.exp Agcc/testsuite/gcc.dg/pch/valid-3.hs Agcc/testsuite/gcc.dg/pch/macro-4.hs Agcc/testsuite/gcc.dg/pch/warn-1.hs Agcc/testsuite/gcc.dg/pch/valid-2.c Agcc/testsuite/gcc.dg/pch/empty.c Agcc/testsuite/gcc.dg/pch/decl-4.hs Agcc/testsuite/gcc.dg/pch/valid-4.c Agcc/testsuite/gcc.dg/pch/include Agcc/testsuite/gcc.dg/pch/include/import-2a.h Agcc/testsuite/gcc.dg/pch/include/import-2b.h Agcc/testsuite/gcc.dg/pch/valid-6.c Agcc/testsuite/gcc.dg/pch/inline-2.hs Agcc/testsuite/gcc.dg/pch/warn-1.c Agcc/testsuite/gcc.dg/pch/cpp-1.hs Agcc/testsuite/gcc.dg/pch/system-1.hs Agcc/testsuite/gcc.dg/pch/static-1.hs Agcc/testsuite/gcc.dg/pch/inline-2.c Agcc/testsuite/gcc.dg/pch/inline-4.c Agcc/testsuite/gcc.dg/pch/struct-1.c Agcc/testsuite/gcc.dg/pch/static-1.c Agcc/testsuite/gcc.dg/pch/common-1.c Agcc/testsuite/gcc.dg/pch/empty.hs Agcc/testsuite/gcc.dg/pch/valid-2.hs Agcc/testsuite/gcc.dg/pch/valid-1b.hs Agcc/
Re: svn access on RHEL 4.0
Try removing the offending directory (gcc/testsuite/gcc.dg/special) and run svn cleanup again, updating the tree afterwards. If you didn't have any local changes in that directory you should not lose anything. If the problem persists then you probably have a hardware problem. Just "for the record": gcc.gnu.org runs RHEL4, and we've never had any trouble like this. All the snapshots are generated locally using svn, etc.
Re: svn access on RHEL 4.0
Bradley Lucier <[EMAIL PROTECTED]> writes: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' > > I first got that message when I tried contrib/gcc_update after doing > a svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. > > > Does anyone have any helpful ideas of what to do? Try removing the offending directory (gcc/testsuite/gcc.dg/special) and run svn cleanup again, updating the tree afterwards. If you didn't have any local changes in that directory you should not lose anything. If the problem persists then you probably have a hardware problem. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: svn access on RHEL 4.0
Bradley Lucier wrote: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' I'm sorry, I'm a little sleepy, in the hurry of trying to "help" I totally missed these lines. :-( -- Pedro Lamarão
Re: svn access on RHEL 4.0
Bradley Lucier wrote: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' > > I first got that message when I tried contrib/gcc_update after doing a > svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. Have you tried doing "svn cleanup" as the error message suggests? -- Pedro Lamarão
Re: svn access on RHEL 4.0
On Fri, Jan 06, 2006 at 10:35:36PM -0600, Bradley Lucier wrote: > I'm having all kinds of trouble running svn on my RHEL 4.0 system. A > typical example of what's happening is: > > euler-62% svn cleanup > svn: XML parser failed in 'gcc/testsuite/gcc.dg/special' > > I first got that message when I tried contrib/gcc_update after doing > a svn checkout. Now I just get > > euler-63% contrib/gcc_update > Updating SVN tree > svn: Working copy '.' locked > svn: run 'svn cleanup' to remove locks (type 'svn help cleanup' for > details) > Adjusting file timestamps > SVN update of full tree failed. > > > Does anyone have any helpful ideas of what to do? > I built/installed svn and related rpms from FC4 on RHEL 4. It works for me. H.J.
