Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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