[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "Concurrent" VS...
Noel L Yap
Re: "Concurrent" VS...
Wed, 28 Feb 2001 07:28:42 -0500
I think you misread my statement (in the context it was given in). Any usable,
scalable process will not have developers changing the exact same files at the
same time. Instead, they will work on different copies of the files. CVS
supports this (and it's obvious you agree).
address@hidden on 2001.02.27 18:24:21
cc: (bcc: Noel L Yap)
Subject: Re: "Concurrent" VS...
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.
Info-cvs mailing list
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.