RE: Working on sources in parallel

[Rod Macpherson]

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: address@hidden
[mailto:address@hidden On Behalf
Of Matthias Kaeppler
Sent: Wednesday, June 15, 2005 10:44 PM
To: address@hidden
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
address@hidden
http://lists.gnu.org/mailman/listinfo/info-cvs