PM
To: info-cvs@gnu.org
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 t
Paul Sander wrote:
CVS notices the conflicting changes and produces a working copy of the
file that contains Person1's removed lines and Person2's inserted lines,
with special mark-ups to draw attention to the problem. It also leaves
copies of both contributors in the user's workspace.
Not q
CVS notices the conflicting changes and produces a working copy of the
file that contains Person1's removed lines and Person2's inserted
lines, with special mark-ups to draw attention to the problem. It also
leaves copies of both contributors in the user's workspace.
On Jun 15, 2005, at 10:44
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
Alright, thanks a lot!
--
Matthias Kaeppler
___
Info-cvs mailing list
Info-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/info-cvs
CVS automation kicked in for you. It recognized a concurrent change and
instructed you to update your local copy before checking in the changes.
Updating before checking in is a sound policy that avoids those errors.
Allows you to do a local integration test prior to checking in.
You just had a d
This is intentional by CVS. So here's the scenario
Person1 & Person2 working on file1.c and hence have
a copy of the file in their respective sandbox.
Person1 checks-in file1.c, updating the repository copy.
Person2 checks in file1.c, CVS complains "Your file is
out of date" (or the like).
Pers
