[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Concurrent" VS...

From: schmolle
Subject: Re: "Concurrent" VS...
Date: Tue, 27 Feb 2001 23:24:21 +0000

Hi list,

I have had to explain this to many people that ought to know better, so I'm 
more than happy to perform the routine for an audience that might be forgiven 
for not realising this. ;)

>[Noel L Yap] I think the problem any VC system is supposed to solve is to 
>prevent multiple people from editing the same file at the same time.

If you are in a situation where there is more than one developer working on the 
same code base, you will at some point be facing the situation of more than one 
of them doing work on the same (set of) files.

It is important to realise that NO tool can solve this problem. The only 
foolproof solution (though not necessarily free from headache) is communication 
between developers.

I like CVS because it will at least allow people to do the work, regardless of 
whether they run into this problem later. The reality is, that it is not likely 
to happen in even the slightest form of organisation. This yields much better 
results than disallowing the practice (i.e. using exclusive locking).

Then there is 'cvs update' and the merge process. Again, this is not to be seen 
as a magic solution. Having CVS handle your merging for you may be a blessing. 
It may also completely ruin the functionality of your program by breaking 
structure in your source code. What I'm saying is that CVS helps, but nothing 
more than that. In the end there is no possible substitue for a human with an 
accompanying brain.

The way this fits in with a bit of CVS advocacy (for those of you that have to 
explain to your boss why he shouldn't spend 40K on a Rational tool): the same 
principle applies to any VC system out there. The difference lies in how much 
assistance you get from the tool in solving the problem.

I should add to this that with CVS, coupled with the average UNIX environment, 
you can quite easily create wrapper scripts that enforce additional layers of 
locking, to suit your business rules.

I did this at my previous company, where anybody could check out, but only a 
select few (the Release Management team) could check code in. The checking in 
was only done for code that was accompanied by an appropriate token.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]