[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Concurrent" VS...
Re: "Concurrent" VS...
Tue, 27 Feb 2001 23:24:21 +0000
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
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
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.