>Frode,
>
>Frode Nilsen wrote:
>>
>> >[ On Tuesday, February 15, 2000 at 09:19:13 (+0100), Frode Nilsen wrote: ]
>> >> Subject: Re: CVS File Locking
>> >>
><snip>
>> >> Couldn't someone come up with a good solution to the problem instead of
>> >> this endless argumenting:
>> >> 1. How do I prevent someone from starting to edit a file that I am
>> >> editing.
>> >
>> >send them e-mail, telephone them, leave a post-it on their screen, fire
>> >them if they make changes to files not assigned to them, etc., etc.,
>> >etc., ad infinitum.
>> >
>> But that is the problem, each and every developer doesn't know who all the
>> other developers are.
>
>I'd like a little clarification on what the environment is that you're
>developing in, that this is the case?
There are two situations that makes this "mess".
1. The developers are situated at different sites, working at different
times etc.
2. Some of the code are libraries that no one thought anyone else was
working with, but they needed a quick improvement.
<snip>
>Indeed, but if your source code is modularized correctly, each developer
>should be working on certain areas of the code, and you (or management)
>ought to know who's been assigned to work on which areas. CVS is
>certainly NOT a substitute for management in that sense. It can't be.
>
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.
And when you have a lot of binary files you don't want to use branches for
your bug fixes, because it gives a lot of trouble when merging it back into
the main trunk. You rather choose to take this trouble with the few files
that slip through the manual locking.
The binary files are LabView files that constitutes the main part of the
project, which are moved over to C/C++ during the lifetime of the product.
>> >> What we (the ones crying for locks) want are some means to force
>>serialised
>> >> work one certain file types.
>> >
>> >Then go find some tool that fulfills this requirement. Do not use CVS
>> >if you don't want to be forced to assume the copy-edit-merge paradigm is
>> >the only one available to you.
>
>The quoting doesn't make clear who said this, but I will say that I
>disagree with this in the sense that I think the existing capabilities
>of CVS for locking are perfectly fine for this type of thing. I realize
>that there's no automated way to tell CVS to use locking on specific
>file types -- but then, there is no automated way to tell CVS most
>anything. That's why God invented perl. :-) I don't, however, believe
>that the capabilities CVS has for locking should be extended.
>
When I said file types I didn't mean that CVS should necessarily recognise
certain files as a given type.
If I just could tell CVS when I added a new file that this file should
always be checked out with a lock it would have solved the problem once and
for all. And it would not give any problems for files that was added as
concurrent files.
Can't you agree that such a solution would have been an improvment to CVS
with no drawbacks ?
Frode Nilsen
MISON AS
Medisinsk teknisk forskningssenter
7489 TRONDHEIM
NORWAY
Phone: +47 73 55 10 67
Switchboard: +47 73 55 10 60
Fax: +47 73 55 10 61
e-mail: [EMAIL PROTECTED]
web: www.mison.no
