Tony Hoyle wrote: > sometimes > 'cvs update' doesn't change the on-disk file, but *does* change the CVS > directory, which > causes a revision to be effectively erased on the next commit. > > It might be that there's a problem when the clocks of the machines > aren't in sync (most of the time > this has happened it has involved a laptop which doesn't automatically > keep in sync like the > desktops do). I have watched it happen in front of me with a desktop, That shouldn't cause the problem. A standard update uses the revision and not the date to compute the diff. All the date comparisons going on should be on the client against records of dates it set in the first place. If the client has an updated revision number then it should have received the patch. > though. I committed a bugfix, > went to the other machine to update, it said it had done the update, but > the bugfix did not propogate. I had > to manually delete the file and re-update to cause the new revision to > appear. I can imagine bad handling of a network glitch, but that doesn't seem likely. If it happens again, can you record all relevant information and attempt to reproduce the bug? Preferrably in script format (i.e. a Bourne shell script I or somebody else can run to see the bug occur)? Try and notice if there were any network errors, as well. Some ideas are to copy your repository immediately after seeing the error, delete the offending revisions from the copy and try recommitting the changes from the original to see if it happens again. Then we can at least narrow this down to something reproducible or bad network code or whatever. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "The only difference between me and a madman is that I am not mad." -- Salvador Dali _______________________________________________ Bug-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-cvs
