Ah. I see. If you are only applying locking to some files (as suggested in the link), then you're probably not going to suffer :)
In a small team, though, I'd still advise not doing it. You just need to make sure that any changes to the resource files or whatever are publicised and discussed in advance of changes. We are a team of seven or eight here, and we don't lock resource files. So far we've not hit a problem. But, of course, you know your own situation best. Cheers Peter -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Caner Sent: 06 January 2009 08:19 To: VisualSVN Subject: Re: Lock-Modify-Unlock problem 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 >
