Hi, Thanks a lot for your advice Peter. We are actually in the case which is described here: http://visualsvn.com/support/topic/00016/ We are developing with C/C++. I agree, if multiple developers work frequently on the same piece of code, there's probably a problem in task assignment. Well, we are still a small project team, and not fully organized. The second issue is that, we should be sure of that we can apply both model with VisualSVN Server before fully settling a system. I will share your email with my team mates.
Thanks again for your concern. Best Regards Caner On Jan 5, 5:41 pm, "Bradley, Peter" <[email protected]> wrote: > Hi, > > I'm sure you've carefully thought out what you're doing and have very > good reasons for choosing a lock-modify-unlock model, but just in case > no-one has brought this to your attention... > > A very large number of Subversion users would advise strongly against > using a lock-modify-unlock system. This is what Pragmatic Version > Control by Mike Mason, 2nd edition, p26 has to say on the matter: > > "In reality, though, strict locking turns out to be a lot of extra > hassle with no particular payback. If you try an optimistic locking > system (such as Subversion), you'll be surprised at just how rarely > conflicts arise ... We've tried both kinds of locking over the years, > and our strong recommendation is that the vast majority of teams should > use a version control system with optimistic locking." > > Our experience is the same. We introduced Subversion after years of > struggling with Visual Source Safe. VSS locks all checked out files and > we were forever having problems with developers not being able to get to > the files they needed to edit. In the end we managed to persuade our > management to go for svn with optimistic locking. I can't tell you how > much easier our life has been since then. > > Remember that you have to have two developers trying to edit the *same > lines of code* at the same time for any conflict to arise. If this > happens regularly for you, the answer might be more easily found in > project management practices than in source control configurations. > > If you've considered all this and still decided you need a > lock-modify-unlock model, then please excuse and ignore me. I just > thought that someone ought to say it just in case you'd missed > something. > > Cheers > > Peter >
