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?

<snip>

> >CVS is not a substitute for management.
> >
> But it is! CVS is supposed to manage a whole lot of files for me, and avoid
> me from keeping av list of which files have been changed when by who for
> what reason.
> And it is not the task of management to know about each and every file the
> developers are working with, thats what they installed CVS for!

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.

> >> 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.

> This is stupid, stupid, stupid.
> I love copy-edit-merge in 99% of the cases, I would be euforic (is that the
> word?) if CVS could have supported that last 1% in a nice way.

The word is "euphoric." :-) And your English is much better than my
Norwegian. ;-)

> a soly copy-edit-merge paradigm can only be used 100% succesfully by them
> who are doing development on their own, or only using text files (in its
> strictest form).

I have to disagree. We use a strict copy-edit-merge paradigm (no locks)
and we are certainly not using only text files nor are we a single
developer. We resolve merge conflicts on non-text files the
old-fashioned way: Communication. In practice, it doesn't happen often,
because we use binary or other non-mergeable file types in the
repository very judiciously (i.e., only when there is no other sensible
way to do it)

Kate Ebneter
Build Engineer and Rabbit Wrangler
DataRover Mobile Systems, Inc.

Reply via email to