Thompson, Graeme (AELE) wrote:
> Yes, we have been in the situation of having files locked when people
> have gone on vacation, but in these cases it is possible to forcibly
> unlock the files and leave the developer a note, thus not stopping
> other
> working on them.
>
> More seriously, from our perspective, is the issues we have had when
> people have tried to merge their changes in with other peoples changes
> and have reintroduced bugs that have already been fixed because they
> did
> not have a full understanding of what they were doing. These bugs then
> take the extra time for someone to track down and then fix them again!
>
> I can see both sides of the argument, and some of my colleagues have
> worked extensively with both methodologies, but for a project that is
> updated 30-40 times a day, and in lots of places that are common, then
> working with the locking methodology has in experience been less prone
> to time wasted merging files and refixing bugs.
Interestingly enough, my first experience with version control was with
a small team on a tight deadline (it was a college project, actually).
We were using CVS, and updated frequently; I remember one time where
four of us were in the lab together, and we probably had fifteen commits
within the space of ten minutes. We never had any problems with
previously fixed bugs resurfacing, for two reasons:
1) We were working on separate areas of the project. One was working on
the GUI; another, the file system, etc. Even when we were working in
the same files, we weren't working on the same section of code, so
conflicts rarely happened.
2) We had a strict "Test your changes after every update" rule in place.
If it had happened that two guys were working on the same bug, and both
thought they'd solved it, and the merged code didn't have the fix, the
second developer knew not to commit his code.
Really, you seem to be looking to subversion to fix your communication
problems--get your developers talking to each other, institute some
basic rules (test the results of any merges!), and you should be fine.
-David
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 17:44:03 2005