[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Automatic merging
From: |
Frederic Brehm |
Subject: |
Re: Automatic merging |
Date: |
Tue, 08 Jun 2004 15:53:34 -0400 |
At 03:13 PM 6/8/2004, Carucci, Jason wrote:
My understanding is that even when CVS does the automatic merging of
changes, it does not commit them to the repository until you OK the changes
is that correct?
Yes, that is correct. The source is merged in your sandbox by the "cvs
update" operation. The "cvs commit" operation puts changes from your
sandbox into the repository. You get a chance to run regression tests
before foisting the merged code on the rest of the team.
What has been the experience with this feature in CVS?
It's quite good for source code. Conflicts are pretty rare, at least for
me. We try to partition our design and work so two people do not have to
change the same portion of a file at the same time.
The only problem I have had is once when there was a project full of
"cowboys" who did not bother to communicate with each other and wanted to
fix everything themselves. The merge problems were a symptom of a
dysfunctional team and no source code control system could fix that.
Early in my employment here, CVS was a big success because of the merge
ability. The software was poorly engineered (it grew from very small to too
big without refactoring) and lots of people were working on it. Many files
had to be changed to fix a single bug or add a single feature. With SCCS
locking, the team members work was effectively serialized. CVS broke the
jam. Even with changes distributed over a large number of files on each
checkin, merging never became an issue.
Fred
_______________________________________________________________
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/
- Automatic merging, Carucci, Jason, 2004/06/08
- Message not available
- Re: Automatic merging,
Frederic Brehm <=