The key is that update does a merge from the repository to your local system. Merge either quietly succeeds or a conflict is detected: first resolve conflicts, build, test and then check in.
Perhaps you have used systems that lock. They have the same problem with the added bonus of introducing development bottlenecks. If only one person edits a file the locks are irrelevant. If more than one person edits the file then problems arise: a local copy is edited and when the lock becomes available a manual merge is required. Frequently, there is no merge and changes made to the repository since the developer checked out are blown away. Lock-based systems arbitrate access to the same file but if you make a local change and ignore the lock you are immediately in worse shape than you would be with CVS. Files that can benefit from serialized access are binaries: you cannot simultaneously edit the corporate logo or a word document because you cannot merge the changes. In those cases locks make sense and CVS does allow locking if you need it. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matthias Kaeppler Sent: Wednesday, June 15, 2005 10:44 PM To: [email protected] Subject: Re: Working on sources in parallel I have another question. Let's stick to the scenario Christopher made up. Say person1 thinks it'd be a good idea to remove some helper-function foo(), and replace it with another function bar(). Then he commits the sources. Person2 still works on the outdated source, where foo() exists, and he thinks it'd be a good idea to introduce a new variable or whatever in foo(), so his changes to the file are limited to the function foo. Now he wants to commit his changes, and CVS complains "sorry bro, update first". Okay, so he does an update, and... now what? What does CVS do in such a situation? How could it merge the two sources, with changes to a function foo() which was removed by person1? So many questions :) -- Matthias Kaeppler _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
