On 13 Feb 00, at 22:30, Tom Satter wrote:
>Mike,
>
>You are correct. It is difficult to write in an e-mail the
>way that I would talk in person. I tend to be much more
>diplomatic in person and I know for a fact that my e-mails
>tend to sound aggressive. I apologize in advance if I
>offend you, that is not my intent.
>
OK
>With regard to your statement about logical arguments, take
>two of the issues that are currently being discussed:
>
>1) locking in cvs
>2) cvs add behavior
>
>When Greg (and you) argue against adding or modifying any
>of the CVS code to support locking your argument invariably
>is that the tool was not designed to be used for locking,
>that this would make the code more complex, and simple is
>better. This in itself is a rational argument -- no problem.
I would say that the argument is really (as others have pointed out) that,
the current 'locking' feature that cvs has is broken and worse than useless --
it appears to give you some security, but in fact gives you none. Its use will
inevitably
lead to developers breaking the locks. If you are lucky CVS will mail the locker to
say
that her lock has been broken. But it's still been broken.
It's only use is to make developer B aware, _after_ he has made his changes and tries
to commit
them, that developer A has locked those files.
That awareness can easily be achieved with cvs watch/edit, _before_ developer B makes
any changes.
And for the specific case that Jerzy, et al are discussing, locks do not help the
situation.
Visual Basic files, or other non-mergable files are just that -- non-mergable.
Mark them as such (it happens to be the 'binary' flag but in this case simply tells
CVS to not
attempt to merge these files)
Given the explicit example of VB files...
Without locking
A checks out module VB
A makes changes
B checks out module VB
B makes changes
A commits those changes
B tries to commit, needs update, does so and is told
cvs update: non-mergeable file needs merge
B wants his changes but rightly doesn't want to lose A's changes.
He has to somehow resolve the problem _by hand_ before he can commit.
Now with locking...
A checks out module VB
A issues 'cvs -L file1.frm'
A issues 'cvs -l file1.frm'
A makes changes
B checks out module VB
B makes changes
B tries to commit and is told
cvs [commit aborted]: Revision 1.1 is already locked by A
B goes to see/emails A
A says "Sorry, I needed to make sure my changes got in...."
A commits changes
A says "...there I've finished now."
B tries to commit -- needs update
B updates and gets
cvs update: Updating VB
U VB/file1.frm
cvs update: non-mergeable file needs merge
cvs update: revision 1.2 from repository is now in VB/file1.frm
cvs update: file from working directory is now in .#file1.from.1.1
C VB/file1.frm
B wants his changes but rightly doesn't want to lose A's changes.
He has to somehow resolve the problem _by hand_ before he can commit.
I really cannot see how locking in this situation helps!
Let us not forget, that as well as cvs admin being explicitly documented as a bad
idea,
unsupported, likely to disappear etc., it is the only command that gives no help, and
is the only
command that is hard-wired out of the box to not be usable by the common or garden
developer,
it is only invokable by members of the cvsadmin group.
>In the 'cvs add' discussion there are really two different
>threads. One is allowing add to be done with a slightly
>[SNIP]
Greg has answered this.
>In the CVS locking discussion it is interesting because CVS
>already supports locking but in a really brain-dead way.
>Now if we really want to make CVS simpler, lets start
>a thread about REMOVING the current locking system. Then
>CVS would only be concurrent and the argument would make
>more logical sense.
Noel Yap has already suggested that locking _should_ be removed
and then the situation looked at again.
>What I was pointing out about the 'no compromise' position
>that Greg has taken is that in the CVS add discussion,
>almost everyone has agreed with having code to support the
>new syntax (part one of the paragraph above). However,
>there has been serious questioning of the value and
>complexity of implementing the code for looking upward
>in the repository for working directories.
I beg to differ. Greg's 'hardline' "it's my proposal so there!" (sorry Greg!) was
explicitly
started because someone suggested that it would be _dangerous_ to recurse upwards.
Greg then challenged anyone to prove that it was dangerous.
There then followed the strange example of users' sandboxes being created below a cvs
managed
workspace. (I say, "Give 'em enough rope...")
Someone else suggested that symbolic links could be a problem, which Greg countered by
agreeing
that yes, symbolic links are a problem. They _are_ currently, without his proposal!
Another responded with some non-specific mumble about mounted file systems.
So you see, no-one has yet managed to prove that recursing upwards is dangerous in
other
than exceptional circumstances. But then other CVS commands are dangerous in
exceptional circumstances.
Mike
--
Share what you know. Learn what you don't.
Mike Little <[EMAIL PROTECTED]>
work: <[EMAIL PROTECTED]>
Web: http://www.ampersoft.co.uk
PGP public key at http://www.ampersoft.co.uk/mike/mike.html
