Tobias Weingartner wrote:
>On Wednesday, February 16, Frode Nilsen wrote:
>>
>> There are two situations that makes this "mess".
>> 1. The developers are situated at different sites, working at different
>> times etc.
>
>I've worked with people on projects all over the world. This has *never*
>been a problem. Not ever.
>
Lucky you.
Have you known who each and every developer was ? From graphical design to
(beta) testers ? so you could inform them about which file that must not be
touched at certain times ?
>
>> 2. Some of the code are libraries that no one thought anyone else was
>> working with, but they needed a quick improvement.
>
>Here is your problem. These "quick" improvements tell me that you do not
>have any management structure within your developers. It's basically a
>"free for all". While this may work in some environments, it usually causes
>duplicated and wasted effort. Communication *WILL* solve this, locks will
>not.
>
When you have to get a fix out to your customer within 24 hours, this is
the way to do it. Other developers are informed about the changes after
they are done.
And yes, I know locking won't support this, but it will inform the
developer what problems he is causing and he can solve it at that moment.
Not a week later when the first developer tries to incorporate his version
2.1 of the library.
If you think communication will solve this, why do you use a concurrent
version control system at all ? It is design to let you forget about
communication !
>
>> That is true, but as always, real life is not so simple. The code stays
>> this modularized for about 6 months, then bug fixes, new features etc.
>> makes their way in and mess things up until someone says 'Hey we need a new
>> design for this solution' and then after 6 new months your code are
>> "correctly modularized" again.
>
>Exactly why managers are paid more. If you have a "mess", your managers
>are not doing their job.
>
Sorry, but at our shop the customers are getting their solutions on time.
What a developer are considering as best practice has no importance.
This is getting out of topic.
I just described why I needed locking. We are not going to change our
development practice because yout think it is bad.
If CVS doesn't support locking (in the future) we have just another item on
our list why to choose another system.
If we do this change I IMNSHO think that would be a shame for CVS and the
Open Source Community, because it shows that it realy isn't that open.
--------------------------------
Why not?
[EMAIL PROTECTED]
