On Friday, February 18, Frode Nilsen wrote:
>
> 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.
I did not say that they would. I merly said that the manager should know
which developer (for a start at analyzing anyhow) should have a look at a
particular urgent bug report.
> >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).
You're missing the point. Or your using CVS in a really weird way. Why
would you not type 'cvs update' in your sandbox to get the latest and
greatest version? (On whatever branch you are currently working on).
>>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.
> ...
Nope. The e-mail can be effectively filtered, or controlled which list it
goes to, depending on module location, filename, etc. Also, the more your
developers commit in an incremental fashion (working code preferably), the
better this works. If you "hoard" code until you are 100% completely done
with it, and then commit in one 10MB chunk which modifies 50+ files, things
will get much more "complicated".
> 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.
True, having 1 person understand 1 part of the code is usually bad. However,
having 1 person (or 1 group, etc) "responsible" for the development of certain
modules, will help with direction, etc. If need be, using branches, such that
"extra" people can commit right away as well, might be a solution. Personally,
I would advocate a model where diffs and/or design documents get (in)formally
approved by the person/people "responsible" for that particular module, before
somebody "simply commits" a fix. Otherwise, how do you keep track of why
certain fixes were made, how long they need to be in place, what their limits
are, etc?
> 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.
I disagree, it is *one* solution that could guarantee that. There are others.
>>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.
Yes, merge conflicts.
> >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.
Open means that you have an "equal" chance of getting your locking support,
as I have to get it removed completely. It means we each have the same chance
of looking at the source, modifying the source, and trying to contribute back
to the project.
> 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.
No, I believe that a lot of these people have demonstrated that they wish
to use CVS (however appropriate in their case) in a sub-optimal way, either
due to software/coding practices, or their own preconceived notions of what
CVS should be able to do.
> (Every problem is not a nail).
True, however, not every problem is to be solved by CVS. You in some sense
must be from the "mainframe/wintel" side of things, where they advocate tools
that can do everything. Most of the original CVS people are from the unix side
of things, where we advocate 1 tool == 1 job.
> 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.
Personally, I've yet to use *any* of the locking type features currently
available within CVS. I've not had a use for 'cvs edit', nor for 'cvs admin'
type "locks".
> 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.
Maybe. I don't speak for people who have commit access to CVS. If it is
sufficiently clean (and there I have my doubts), and far enough out of my
way, in such a way that it would not impact me in any way, I would not have
much trouble with CVS having locks.
However, if CVS changes, and I have to change my current concurrent use of
CVS, a tool which I *specifically* picked for its concurrent features, I will
be a very unhappy man...
--Toby.
