[EMAIL PROTECTED] on 04/05/2000 01:33:39 PM
>I'm sure that myself and other people could adapt to this new definition, but I
>still prefer the idea of a design that prevents as many mistakes as possible.
This isn't a new definition, it's always been documented this way.
Exactly which mistakes are you talking about? If it's the possibility of doing:
cvs edit file
# modify file
cvs unedit file
cvs ci # accidental commit of file's modifications
I've already said that the current implementation in no way prevents this:
# modify file
cvs edit file
cvs unedit file
cvs ci # accidental commit of file's modifications
Also, the forth-coming "cvs ci -c" patch will help prevent these sorts of
mistakes.
>It seems to me that many users of CVS use 'cvs watch' and family to enforce
>communication and as a substitute for reserved checkouts. I have persuaded
several
>developers to use CVS simply because 'cvs edit' and family seemed like a viable
>substitute for reserved checkouts and I have seen similar discussions on this
>list. It simply doesn't do me much good as a developer if I am watching a file
and
>it gets 'cvs edited' and major changes are checked in all in under five
minutes.
Nothing in my proposal changes this. It's suggested that developers "cvs edit"
the file before committing, but the tool cannot enforce this. Nor can the tool
enforce when developers "cvs edit" the file.
>Now, I understand that a determined developer could get around the 'security'
of
>'cvs watch', 'cvs edit', and 'cvs unedit', but your design seems to make it
much
>easier to misunderstand the intention of the tools, I think. A less
experienced
>developer, or even a more experienced one who thinks themself in a hurry, is
less
>likely to remember to 'cvs edit' and 'cvs unedit' at the correct times, I
think, if
>they do not have to do so to edit and commit the file. More work for the other
>developers on the team (and possibly the people on this list) if they must
spend
>extra time explaining, berating, chiding, bribing, and cajoling the errant
>developer into remembering to use these communication tools.
>From your previous comments, you obviously understand that the intention of the
tool (ie "cvs edit" and family) is communication. How does my proposal (for
"cvs unedit" not to unmodify the working version of a file, but rather just to
perform its real duties of communication) make it "much easier to misunderstand
the intention"? I should make it clear that "cvs edit" will still make the file
writable and "cvs unedit" will make it unwritable.
So, given that the developer forgets to "cvs edit" and "cvs unedit" at the
correct times, the second scenario above will occur with the current
implementation -- what's the problem? CVS doesn't force anyone to "cvs edit" to
begin with -- I still don't see what the problem is.
I really don't understand your point. Can you please elaborate and preferably
give an example?
>In response into your comments on the clarity of which file to restore after an
>unedit, it would probably be reasonable to update the "Base" when the "edited"
file
>is updated. Then when the file was unedited the new file should match (tag,
most
>recent on branch X at time Y, whatever) the others in the directory. In this
case
>the "Base" file remains unnecessary, except as a cache so 'cvs unedit' may be
>called offline.
The design of both "cvs edit" and "cvs unedit" is to allow offline work. IMHO,
"cvs unedit" should not unmodify to the BASE revision (or to any revision for
that matter). If, OTOH, one wanted to do such a thing (within CVS), I wouldn't
know how to maintain the offline capabilities with consistently retrieving a
BASE copy without a lot of overhead (eg keeping copies of all files around even
before "cvs edit" is done) -- I think it's impossible.
>Now, if you could install something on each machine that called 'cvs edit' any
time
>somebody 'chmod +w'd the file and removed the person from the editor list if
they
>'chmod -w'd the file without changes and such. I'd probably be as happy, but
that
>sounds like something that somebody would have to bend over backwards to
implement
>completely and would probably be a bit painful to install on each and every
>client. Very painful if you actually wanted to watch the file AFTER a 'chmod
-w'
>for "loss of changes".
Not only this, but there're many times I "chmod +w file" instead of "cvs edit
file" since all I'm doing is putting in debug code (in fact, using emacs, I
don't even have to "chmod" any more). Again, "cvs edit" is a communication
mechanism by which you tell others you plan to commit the changes you're
currently working on. In fact, another idea I'm playing around with is to allow
developers to describe their edit sessions (eg "cvs edit -m 'fixing bug 1024'").
Given this, you wouldn't do "cvs edit -m 'putting debug printfs; dont intend to
commit' file", would you?
>I would be all for having 'cvs unedit' create a backup of the modified file
before
>restoring the "Base" copy of the file.
Which still doesn't guarantee that the file is clean.
>That should prevent the data loss and now
>restoring the modified version is simply an extra step - most of the added
>functionality you were proposing, if I understood you correctly.
No, one more time, since the file isn't guaranteed to be clean (ie the developer
modified the file before "cvs edit"), mistakes will still occur.
OTOH, if "cvs unedit" never unmodified the file to begin with, there'd be no
data loss at all.
>I think it would
>be less work the majority of the time to restore the file from this backup when
you
>decided you didn't really want to throw your changes away than it would be to
>remember to back it up yourself and restore the version you desired (a three
step
>process, including the call to 'cvs unedit'). Incidentally, your model might
even
>cause MORE data loss since someone skipping the backup step might not have a
backup
>to restore from.
Why would you need to back it up yourself if "cvs unedit" never changes the
file? If you really did want to throw away your changes, you'd still have to
"cvs up -C file" (or its more complicated counterpart) anyway to absolutely
guarantee a clean copy.
>The short version of all of this is that I am viewing, and believe others view,
the
>'cvs edit' family of tools as security and training tools, as well as
communication
>tools and it looks to me like you are proposing the removal of some of that
>functionality.
I still don't understand. My proposal does nothing of the sort. I'll spell it
out again:
"cvs edit" will create a backup of the file and notify watchers.
"cvs unedit" will not unmodify the file while still notifying watchers.
"cvs ci" will still commit modified files.
As separate proposals/patches:
"cvs edit -c file" will abort the edit if others are already editting file.
(done)
"cvs edit -f file" will force the edit of file. (done)
"cvs ci -c" will abort the commit if a valid edit doesn't exist.
>On a side note, what happens to the email notifications and fileattr
modifications
>when 'cvs unedit' and 'cvs edit' are called offline, anyhow?
The commands are buffered (within CVS/Notify). The next time you're online and
perform a CVS command, the commands are sent to the server. Therefore, nothing
happens to email notifications and fileattr modifications when working offline.
Noel
