Tobias Weingartner wrote:
>On Thursday, February 17, Frode Nilsen wrote:
>> 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 ?
>
>Huh!?! Lucky? I've been on the bloody net, working with people since the
>mid-eighties. I've been working with some version of CVS for almost that
>long (I remember the "original" shell scripts...) Why tell people that files
>must not be touched? On mergable files, this should not be a problem. On
>files that are not mergable, 1 person is responsible for commiting the file.
>
>
Mergeable files has never been said to cause any troubles. And locking is
about defining who that "1 person responsible for committing is".
That shouldn't be so hard to understand.
>> >> 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 if another developer has that "library" locked, you break the lock, to
>get your fixes out to the customer within 24 hours? So locks will not help
>you with this...
>
>
>> 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.
>
>Huh!?! Again, communication will solve this. The manager tells the developer
>that this or that needs "solving/fixing", right now. Part of the "hiring"
>agreement is that fixes of a certain type need to be done within 24 hour
>period.
>
The manager doesn't know exactly what files/libraries that needs to be
fixed. He is just concerned about the user feature that is broken. ie. no
help from that part.
>Also, one of the most important things I've always been teaching, is "update
>often". This is both to keep things in sync, and keep you uptodate with what
>is happening in the rest of the tree. The more often you update, the easier
>conflict resolution tends to be, and the sooner you know about any conflicts
>starting to occur.
>
You don't update a broken library (unless you have a way to define a
migration path, which CVS lacks).
>Also, being on an e-mail list from commitinfo, a list which simply e-mails the
>list of files modified plus the commit message, goes a long way towards
>keeping
>everybody informed what is being worked on, and what has changed. So much so,
>that updates can be done in a fairly intelligent manner, instead of simply
>"often".
>
They give you information when problems had occurred, not stop you from
making them (as locks would). And with lots of developers such an email
flow just generates noise.
...
>
>> >> 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.
>
>Wow. May I ask how the general model goes? IE: developer A is "responsible"
>for library A. A customer comes along with a problem, and it is traced to
>library A by developer B. What does developer B do? Communicate with A (who
>may have a fix already in his sandbox), or "simply" fix code he is not really
>knowledgable about, causing duplicate effort to be exerted?
>
Where do you got the responsible developer idea from? That is not the case
in a project oriented organization. And in other situations it is dependent
of the number of persons involved in the product development.
We don't have source code that is dependent on the memories of some guy, if
you have that I think you should reconsider your development practises.
>
>> 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.
>
>In a lot of people's opinion, you've just described a reason for more
>concurrancy,
>not serialization and locking. Your development practice may be very
>good, esp.
>if you are getting the job done on time. However, I'd question your
>communication
>and management practices...
>
This whole discussion started because we have lots of files in our source
tree that are non merge able -> we have to assure serialized work on these
files. Hard locking is the only solution that guarantees that.
>
>> 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.
>
>Sure it is. Is your software freely available for me to browse, and see what
>sort of coding practices, code organization, and other structure there is
>within it?
>
Nope. I think you would find it on the average, but we have lot of non
merge able files (LabView) that sometimes creates great problems when
someone have tried to edit them concurrently.
>Open does not necessarily mean that it is "bend to the whim of the masses".
>
Here we are getting philosophical, but open means open. If you know of some
"small writing" on the back of the paper, please show me where I can find
it.
And I don't think locking can be caracterized as a whim, it is something
that is used in a lot of VS systems and this thread IMO has showed that it
also has a place in CVS that is mainly a concurrent system. (Every problem
is not a nail). Even thoose resisting locks have showed the need of locks
in some cases, where you already in the cvs add command could have tould
that concurrency is not applicable for this file. And by doing so they
whould have saved them self a lot of work later on, without any extra work
caused by the locks on these files.
If someone writes a patch that clean up the use of locks as of today in CVS
it should be accepted as a part of CVS, not rejected because of the C in
CVS.
Thats it, I am out of this discussion.
--------------------------------
Why not?
[EMAIL PROTECTED]
