> -----Original Message-----
> From: Gale, David [mailto:David.Gale@Hypertherm.com]
> Sent: 05 December 2005 16:32
> To: Thompson, Graeme (AELE); Andy Levy
> Cc: users@subversion.tigris.org
> Subject: RE: RE: Checking out files to default to read-only
>
> 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
>
This is one of those scenarios where there is no black and white answer.
Both systems have their advantages and disadvantages. It is possible to
come up with compelling arguments for both sides.
I really like subversion, and this svn:needs-lock I believe will get the
system to work in the way that I would like.
Thak you,
Graeme
******************************************
The information contained in, or attached to, this e-mail, may contain confidential information and is intended solely for the use of the individual or entity to whom they are addressed and may be subject to legal privilege. If you have received this e-mail in error you should notify the sender immediately by reply e-mail, delete the message from your system and notify your system manager. Please do not copy it for any purpose, or disclose its contents to any other person. The views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of the company. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused, directly or indirectly, by any virus transmitted in this email.
******************************************
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Dec 5 18:17:23 2005