> > > With the -s option, cvsup will not touch files that it believes are > > > in sync until they are updated on the server. > > ^^^ > > not ? > > no, not "not". "cvsup will not touch files that it believes are in > sync", the operative word here being "believes" - with -s cvsup will > use the checkout list and won't even look at the actual file unless > the server says it has a newer version than what is listed in the > checkout list.
I think we're having a mis-communication. I want cvsup to edit the files that are in sync with the master server. I want cvsup to ignore or leave alone files that are out of sync with the server (ie: don't re-transfer the file in the assumption that its been "corrupted"). We working from the same set of intentions and just colliding in the communication dept (most likely what it means to be in "sync")? > > -s is a bit dicey to trust unless you grab an exclusive lock on > > the file and prevent other people from making a change to the file > > on the server. -sc > > You actually *want* the -s induced failure in this case. If -s induces a failure when there are local changes that haven't come down from the master repo, that'd be slick... it still sounds like you'd have to clear your ,v file if you commit your changes after someone had made a change to the file after you made a local commit. [local commit to file A ] [different developer commits to file A on master repo] [commit to file A on master repo] [cvsup local repo with master repo] Wouldn't you have to delete A,v before A,v would continue to pick up future changes? -sc -- Sean Chittenden To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message