re: Problem: newly creating local CVS tree using CV
(to the moderator)
About the CVS tree creation problem which
I have reported earlier,
I think I have found the cause of the problem.
I believe that the cause is a certain
network connection time restriction mechanism
in place somewhere on the network where
the xfree86 hosts are located.
The gist of my discovery:
It seems that the connection to xfree86 cvs server
is cut after a maximum limit connection time is reached.
This connection resets affects the CVS
copy operation and its restarting capability.
Compression in cvs command changes
cvs copying time
and cvs program was in a different state
when the network connection reset
occurred. I could restart
the cvs command, and it seemed to
have succeeded in creating a complete local cvs tree
when the compression was enabled.
Details.
Using "cvs -z 2 checkout xc",
with "-z 2" to compress the data before sending out to
local PC from cvs server,
I got the following message during the execution before
cvs command was aborted due to unexpected
connection loss.
--- quote ---
... many lines beginning 'U' meaning updating/copying
... the files
U xc/programs/Xserver/dix/property.c
Read from remote host anoncvs.xfree86.org: Connection reset by peer
cvs [checkout aborted]: end of file from server (consult above messages
if any)
duron:/ide-s-master/tools/xfree86-cvs# ~ishikawa/bin/fetchx11.sh
[EMAIL PROTECTED]'s password:
? xc/programs/Xserver/dix/.new.resource.
--- end quote ---
Now, it seems something on the network didn't like the
connection and reset it. (Maybe the log on the xfree86 server
may reveal the cause of this.)
But important thing is this:
cvs checkout modulename logs messages to stderr.
Looling at how and when the messages are generated, we can
say the following:
(a) there is a period of silence once a new (sub)directory
is entered. Presumably, cvs command is creating an internal
list of files to be updated (under that
directory) by exchanging information between
the server and client. During this period, the log messages are
not printed.
(b) Once the update list for the subdirectory is made,
the real copying(updating) begins and the name of
each file in the list
thus copied is printed with 'U' at the end of the beginning.
The copying is done one by one and the lines starting with 'U'
is printed accordingly. Depending on the size of the file
there could be a lengthy pause before the next such
line is printed.
The cycle consisting of (a) and (b) are repeated recursively
for the subdirectories until the whole copying is complete.
Now, what I found is this.
If we interrupt the operation of cvs command during stage (b) above,
cvs command can be restarted in midway where it stopped, and
we can continue checking out the xfree86 cvs tree as if
nothing has happened.
For example, please note that the copying started
without complaining in the above log snippet.
On the other hand, based on my
observation of cvs tree creation failures this morning and
yesterday, I think that if cvs is interrupted during (a) or during some
timing-critical execution by the resetting of
network connection, cvs command may not leave a state information
and it stops right there. No amount of coercing by
rerunning "cvs checkout modulename" won't work.
My wild guess is that during my first run without compression
flag, "-z 2", the long connection
causes the presumably the connection limiting timer
installed somewhere (I am sure this is not on
my side of network) to kick in during the stage (a),
and thus cvs stopped prematurely.
It left no intermediate state information
for restarting in the future.
Thus I saw the incomplete CVS tree as I have reported.
(I did try to rerun the command, but it didn't
restart successfully.)
However, with the compression flag "-z 2",
the (light) compression changes
the execution time. The change was
enough so that when the connection time limit was
reached and the connection was reset by some daemon or somthing,
cvs on my local PC was performing the stage (b) and
thus the resetting of the connection still permitted
cvs command to leave a state information. So I could
restart the copying invoking the same cvs command again.
(I got lucky this time!)
The above is admittedly a very wild guess,
but the only reason I can think of my
adding "-z 2" in my old script is probably
I saw something affecting cvs operation in
a critical manner without it, and thus
the addition. My memory is so hazy and so I can't recall
what troubles I had one or two years ago when I tried
cvs tree cloning via 64kbps ISDN line...
OK, the once restarted "cvs -z 2 checkout xc" ended
with the following final lines.
--- quote ---
...
cvs server: Updating xc/workInProgress/record/programs
cvs server: Updating xc/workInProgress/record/programs/Xserver
cvs server: Updating xc/workInProgress/record/programs/Xserver/Xext
cvs server: Updating xc/workInProgress/xsm
duron:/ide-s-master/tools/xfree86-cvs# ls xc
CVS Makefile config include registry
INSTALL-X.org RELNOTES doc lib util
Imakefile RELNOTES-X.org extras nls workInProgress
LABEL bug-report fonts programs
duron:/ide-s-master/tools/xfree86-cvs#
--- end quote ---
There is even now the missing fonts/encoding directory!
I have started
make World >& world.log &
on my linux PC to see if it my attempt was successful.
(Sometime later)
Indeed, the execution was carried out to the end without
problems of incomplete CVS tree.
The network connection limit problem
might be a rarely seen problem by many,
but you might want to put a CAVEAT section
or something like this in the CVS page at www.
(My using ISDN 64kbps connection might be stretching
the network usage a little.)
You might also want to mention "-z 2" compression flag.
Thank you in advance for your attention.
PS:
The only mysterious error I found in the
world.log after the local CVS tree
was re-created and the compilation was attempted
was the following Fontconfig error, but
I think it has nothing to do with the CVS tree
creation problem.
Not sure which file is referred to by the "line 17"error.
--- begin quote ---
making all in fonts/scaled/Type1...
make[5]: Entering directory
`/opt2/ide-dir/tools/xfree86-cvs/xc/fonts/scaled/Type1'
LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/mkfontdir .
set -x; LD_LIBRARY_PATH=../../../exports/lib
FONTCONFIG_PATH=../../../lib/fontconfig ../../../exports/bin/fc-cache .
+ LD_LIBRARY_PATH=../../../exports/lib
+ FONTCONFIG_PATH=../../../lib/fontconfig
+ ../../../exports/bin/fc-cache .
Fontconfig error: line 17: not well-formed (invalid token)
Fontconfig error: Cannot load default config file
make[5]: Leaving directory
`/opt2/ide-dir/tools/xfree86-cvs/xc/fonts/scaled/Type1'
--- end quote ---
After checking around, my guess is the file in question is
xc/lib/fontconfig/fonts.conf
On line 17, the date when the file was created, namely
August 4th, is written in
xml comment-like construct. One problem on that
line is the use of Japanese month character for the
date. Probably the program fc-cache is complaining about
the usage of non-ASCII character as it parsed
the contents of the file.
[end of memo]
_______________________________________________
Newbie mailing list
[EMAIL PROTECTED]
*** To unsubscribe , or change message options, see:
http://XFree86.Org/mailman/listinfo/newbie
