Noel L Yap wrote:
>
> [EMAIL PROTECTED] on 2000.07.20 13:37:52
> >>Yes, this behaviour is consistent with OOTB CVS (ie without "cvs
> >edit"). For
> >>example:
> >>cvs co module
> >>cd module
> >>cat hello >> file # OOTB CVS has files read-write
> >
> >What does OOTB mean?
>
> Out of the box.
>
> >>cvs ci # will checkin file
> >>
> >>If you don't want this behaviour, use the "cvs ci -c" patch which'll
> >check for
> >>valid edits before committing.
> >
> >So, if I understand you correctly, I can "cvs unedit" a file which
> >will still leave it in its modified state and then check it in.
>
> Yes.
>
> > I
> >assume that the watchers will get the "commit" notification but they
> >won't get the "edit" notification because the developer has used
> >"unedit".
>
> They would get the edit notification when the user first did "cvs edit". They
> would get the unedit notification when the user did "cvs unedit". They will get
> the commit notification when the user did "cvs ci".
>
> > I don't quite see the point in having edit watches if they
> >can be defeated like this but they can also be defeated by using
> >chmod.
I couldn't agree more. Of course you can use chmod or other trics to
defeat the system in any case. The important thing is that an unedit
that does not revert makes it possible to committ the edited file by
accident if the developer forgets to revert the file manually. There is
a very significant differenct between a tool and user interface design
that can be overridden by a skilled user, and a design that makes these
kinds of accidents possible.
> Exactly. "cvs edit" and family are meant to /facilitate/ communication.
> They're not meant to enforce communication. For example, I habitually chmod
> when all I want to do is add a debug printf. If later I find that I really want
> to commit the file in the future, I'll "cvs edit" it.
I my mind, a good version control system should always enforce
consitency and safety by default (but let you break the rules if when
have to). The described edit/unedit behaviour seems to follow the
opposite philosophy: Do it right if you want to... I really don't think
that is a good idea. Others might dissagree.
I'm really really happy that WinCVS wraps this stupid CVS behaviour for
me to make edit/unedit behave in a logical and sound way. If I have the
time I will look into a way to make CVS 1.10 make the files in the
"Base" folder write protected to prevent myself and other developers
from inadvertently editing these files after double-clicking on the file
in the search result list in Developer's Studio. That's the only change
I need. I somebody knows how to do this or have already done so, please
let the rest of us know.
I might check in RCVS later to see in which direction things are going,
but I'll think leave you alone for now. Things seem to be going in the
wrong direction here at the moment.
- Helge Penne
