On Sat, 28 Jan 2012, Nick Holland wrote:
>On 01/28/12 09:12, Dave Anderson wrote:
>> Thanks for the info. I've been using -Pd because
>> <http://www.openbsd.org/anoncvs.html> says to use them; I haven't yet
>> had a chance to look into how cvs works beyond reading the man page,
>> faq, etc.
>
>and please continue to use them.
>-Pd is the RIGHT way.
I plan to. Dropping them felt kind of iffy; thanks for the confirmation
that it isn't the way to go.
>Apparently, Philip gets away with it, but he's a developer and he knows
>this stuff pretty well, we don't expect ordinary users to clean up the
>mess it can make. I'll defer to his expertise on coding and probably
>CVS, but there are many things in many parts of the tree where a lack of
>a -Pd will hurt you in ways other than slow updates. There are
>thousands of ways to use cvs incorrectly, -Pd is the correct way to do
>updates (or maybe -PAd under some circumstances).
>
>
>And none of this has anything to do with your real problem. I run far
>slower hardware than most people, and xenocara updates don't take nine
>hours (and if I understand you, that was nine hours then you gave up and
>killed it). This has NOTHING TO DO WITH COMMAND LINE OPTIONS. I wrote
>the FAQ you used, I use that FAQ, and I do it on hardware like mac68k
>and sparc, and it works, it does not take nine hours to update xenocara
>(it just feels like it...)
No, it was about 9 hours from issuing the cvs update command until there
was any visible action; the update ran to completion in a total of about
11 hours. I've killed some other update attempts which ran even longer
without any visible action.
>If you could...next time you see this, use a
> CVSROOT=anon...@obsd.cec.mtu.edu:/cvs
>and see if things run better. NOTE: DO NOT GET USED TO USING THIS
>MIRROR, IT IS BEING SHUT DOWN VERY SOON. But, being it's been being
>advertised as being shut down, it's pretty lightly loaded, and it
>handles the CVS temp directory as an mfs, which really really helps
>(this is on the server end. Nothing you can do about it on your side).
>My hunch, as a soon-to-be former mirror operator is that you are having
>a problem with your mirror of choice, not a problem on your end, and it
>may be a problem with multiple mirrors.
I've tried 3 or 4 different servers, and have had this problem with all
of them (at least some of the time).
>I just checked out xenocara from that mirror, and then did an update on
>my amd64 system, the update took less than one minute. Your results
>will vary, but not to nine hours, unless you are using dialup. :)
I do have a slowish ADSL link (384Kbps/1536Kbps) which would limit me to
very roughly 1MB/min outbound, so I took advice to use '-z 9' to
compress data and that reduced the total time for a xenocara source tree
update from about 11 hours to about 2.5 hours. (Though I discovered
that not all servers support compression.)
Then I did a test update of xenocara against your server (still using -z
9), and the entire process took barely 1 minute. I then retried that
upgrade against the server I've been using (anoncvs.comstyle.com), and
the total time was just under 3 minutes. As a final (for the moment)
test I did (against my usual server and with -z 9) an update of my
entire source tree and the total times were src: 7:37, xenocara: 3:55,
ports: 41:58, and www: 2:39 -- for a total of about 55 minutes.
I've no idea why I'm suddenly getting so much faster responses.
Does cvs update send a potentially large but extremely variable amount
of data from my system to the server? If so, that (plus my slowish
uplink) might explain some of these timings. But the cause of these
massive variations is not at all obvious from where I sit.
Thanks for any further info.
Dave
--
Dave Anderson
<d...@daveanderson.com>
