This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Serious problems accessing cvs
- To: gcc at gcc dot gnu dot org
- Subject: Re: Serious problems accessing cvs
- From: Phil Edwards <pedwards at jaj dot com>
- Date: Tue, 7 Mar 2000 17:39:28 -0500
Jeffrey A Law writes:
> In message <200003072123.WAA01557@loewis.home.cs.tu-berlin.de>you write:
> > I'm not entirely certain about that. I notice that updating works
> > quite well when I have no local changes. As soon as it starts merging
> > at the other end, it won't come back. I then kill the update, restart
> > it again, and it sometimes succeeds with the first file to merge, then
> > hangs again.
> The more local changes you have, the more data that has to be moved across
> the wire. For each file you change, assume that a copy of it has to be
> moved across the net at least once, possibly twice (I'm not a CVS expert, I
> can only report what I see in practice).
I would /highly/ recommend using or adopting local tools like what Mike
Stump talked about. Personally, since my connection to the net is often
beaten down to a 300 baud accoustic coupler made out of tree bark and
animal skins, I do:
- a checkout or update
- copy the directory tree
- hack on the copy
- do a diff between the trees and save it to a file
- edit the file to make certain I'm not patching anything I shouldn't
- apply the patch to the "real" local tree
- do the CVS work inside the real tree, restricted to the list of
files in the diff
This obviates a lot of the need for "cvs diff" and "cvs -n update"
and the like. Much of this (all of it?) is already in the web pages
as recommended practice. Always specifying a list of files/dirs to
work on instead of defaulting to everything has a sizeable speedup on
my CVS checkins. In the work I do, there isn't a lot of merging, so I
can't report any experience there.
Phil