[EMAIL PROTECTED] on 2000.04.05 17:53:13
>> 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
>
>I hadn't considered this second case previously. I'm still not sure I think
your
>solution is best here, however, and the current implementation prevents
mistakes in
>the first scenario. I'll touch this again shortly.
My "solution" doesn't address the above scenarios at all (it's handled by the
"cvs ci -c" proposal). I had posted the above to show the falacy in the
statement, "If 'cvs unedit' unmodified files, it would prevent accidental
commits."
>> Also, the forth-coming "cvs ci -c" patch will help prevent these sorts of
>> mistakes.
>
>Nice. Maybe enough to prevent the unwanted checkins, but data loss remains
>possible. See below.
>
>[Old dogs want new users to have trouble committing by accident and committing
>changes they didn't know the new users were working on. On a good team this
helps
>foster communication and leaves fewer messes to clean up.]
Yes, I agree (with the second paragraph).
>> 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.
>
>No, but I think many people could treat a read-only file as a polite reminder
to
>use 'cvs edit'.
>
>[Tougher to err, not impossible]
If "cvs watch" is on, files will still be checked out read only. When "cvs edit
file" is done, it will still make the file read/write. When "cvs unedit file"
is done, it will still make the file read only.
>> >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.
>
>Okay, I WAS under the impression that not changing the files at all included
not
>changing their permissions. Also, we may disagree about the intention. Again,
>I'll get back to this.
I should've been clearer about this. When "cvs unedit" doesn't unmodify the
file, it means it doesn't modify the contents; it will still make the file read
only.
>> 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?
>
>First skipped point: I think the 'cvs edit' family of tools are communication
>tools intended to make it tougher to edit shared files without communicating
first.
Agreed. This is even better with the "cvs edit -c" patch.
>Third skipped point: To further this intention, I think it would be preferable
to
>move in the other direction. i.e. Have 'cvs edit' print a warning or require a
>'cvs edit -f' when it finds that the file to be edited has been modified. This
>could possibly mean exhibiting this behavior just because the timestamp has
changed
>when offline. Also, make the 'cvs ci -c' the default behavior for a commit and
>require a 'cvs edit -f' (as above. This could just print a warning but I think
I
>would opt for the strict case here - it prevents missing the problem when
>recursing.)
What happened to the second skipped point?
I would opt for the "cvs edit" warning -- this would have to part of a separate
proposal. Currently, I have no need for such a thing, so someone else would
have to the work (but I'll keep it in the back of my mind).
I'm not going to change the default behaviour of "cvs ci" and break multitudes
of users' processes. Many (most?) users don't use "cvs edit", why should "cvs
ci" check for such edits.
>Hmm. Okay, I think that's too strong (it might break wrapper scripts). I
guess I
>would find the '-c' flag satisfying, since it would allow configurability and
get
>most of these features, but I think I would still want the save/restore
>functionality of edit/unedit. I would also want the "check for modification"
>functionality I just mentioned added to 'edit -c'. I'll provide an example
near
>the end.
I've shown that if "cvs unedit" unmodified the file, there's no way to guarantee
that it's clean. I don't understand why you would prefer "cvs unedit" to leave
the file in an unknown state rather than keep the known state (of having
whatever modifications it already has).
>[Restore the version of the files that matches tags with other files in the
>directory]
If you want to pursue this, make your own patch. You'll see that once you start
looking through the code, this cannot happen (without a major redesign of "cvs
edit" and family).
>> 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.
>
>Well, you would be limited to restoring either the modified initial version or
>nothing in the case where everything took place offline. Once a single update
>happened, however, it could be treated like calling 'update -C' on the Base
>revisions.
Again, I don't understand why you would want to keep the files in an unknown
state. More than that, the state would now be dependent on whether CVS is
online or offline.
>[Track chmods instead]
Although "cvs edit" and "cvs unedit" do a "chmod", "cvs edit" and family do
other things as well (ie assist in communication). This means that the intent
of "cvs edit" et al and "chmod" are completely different.
>> 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?
>
>My 'cvs edit -c' and your 'cvs ci -c' would seem to keep these kind of changes
from
>being committed easily.
The "cvs ci -c" patch is sufficient. Before doing a "cvs ci" developers really
should do a "cvs diff" to be sure everything they're committing is what should
be committed (eg there's no debug code left).
>[cvs unedit should back up file, thus preventing data loss]
There's no data loss if "cvs edit" did the backup and "cvs unedit" never
unmodifies the file. I've said this before, what don't you get about it?
>> 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.
>
>Again, my 'cvs edit -c' avoids this.
I didn't know you were working on a "cvs ci -c" patch as well.
>> OTOH, if "cvs unedit" never unmodified the file to begin with, there'd be no
>> data loss at all.
>
>['cvs unedit' not backing up requires manual backup to prevent data loss].
Can you please explain what data loss you're talking about?
>> 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.
>
>I'm not sure about 'cvs up -C file', but 'cvs up -P file > file' doesn't leave
any
>backups sitting around.
Then, yes, you're responsible for such backups. It's exactly the same as "vi
file". If you didn't want to take the chance of damaging the file, either back
it up, or don't do "vi file" or "cvs up -p file > file". I don't understand
your confusion. If you *wanted a clean copy* you do "cvs up -p file >file". If
not, don't do it. What's the problem?
>['cvs edit' family are security and training tools as well as communication
tools.]
Please point out where in the documentation this is stated.
>> 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.
>So, my proposal:
> "cvs edit" will create a backup of the file in Base, chmod +w the file, and
>notify watchers
> "cvs unedit" will backup the file, restore the copy from Base, chmod -w the
>file, and notify watchers
> "cvs up" will update files in Base as "cvs up -C"
> "cvs ci" will still commit modified files, chmod -w the file, and notify
>watchers
>
>And:
> "cvs edit -c file" will abort the edit if others are already editing the
file
>or if the file is different from the version in the repository
> "cvs edit -f file" will force the edit of the file
> "cvs ci -c" will abort the commit if a valid edit doesn't exist.
I should've included chmod'ing in my descriptions of "cvs edit" and "cvs
unedit".
Anyway, you're welcome to pursue your proposal.
>I think this is consistent with all the scenarios you described, and, in
>combination with '-c', users should end up with unwanted data checked in less
>frequently. There is also still a backup sitting there (locally, I would
think),
>if you want the data back after an unedit.
Again, you can pursue your proposal. You can even use my patches to start with.
Noel
Enc:
This is my latest comprehensive patch (it includes everything I've done). Note
that it currently does not compile under NT (I need to add some SERVER_SUPPORT
guards).
(See attached file: multiple-edit.diff)
multiple-edit.diff
