[cvsnt] Re: Update problems - file XXX was lost

[Tony Hoyle]

Chuck Kirschman wrote:
> Hmm - a typical workflow is to do a "cvs -nq up" at the top level and
> then start committing the files you are certain about.  When the update
> is done, you can find the files in remote directories that you missed.
> I don't think that's unsafe in that case because it's not changing the
> files.  I've never seen any changes wiped in 5 years of using vanilla
> CVS, even if I'm doing a real update while editing.  After all, what are
> you supposed to do during the 5-10 minutes or so that it takes to do an
> -nq update?  (A real update takes a bit longer)

If you're just committing following the update it'll (probably) be OK, 
but you have to watch the directories being rewritten on the way back 
out of the recursion.

It's still not a good idea though and it's not something I'd be prepared 
to support.  The client behaviour may change and unexpectedly break it.

If you're taking 10 minutes to upgrade then that's a lot of files - you 
may be able to just update parts of the tree (depends on the project and 
how isolated your working environment is).  Compression (-z3) may help 
too.  The worst case is you may just end up waiting for it.

> And what is causing the differences in behavior between the clients
> then?  If the server is sending the same information back, does the
> vanilla client display it differently?

It's possible there's a special case in the new clients for something 
that's changed in the server.  It's difficult to tell without looking at 
traces of the communication between the client and server...  Last time 
I checked they were identical but trying to modify files during an 
update isn't something that's ever been coded for.

Tony