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.
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.
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.
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.
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".
I would be all for having 'cvs unedit' create a backup of the modified file before
restoring the "Base" copy of the file. 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. 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.
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.
On a side note, what happens to the email notifications and fileattr modifications
when 'cvs unedit' and 'cvs edit' are called offline, anyhow?
Derek
Derek R. Price
CVS Solutions Architect
303.554.8291
[EMAIL PROTECTED]
http://alumni.engin.umich.edu/~oberon/resume.html
--
I used to look down on people crazy enough to get tattoos. Nowadays, I envy them
that clarity of thought. There was at least one point in their lives when they
thought they knew what they were doing. They could walk into a tattoo parlor and
say, "I want a big old pig, in red and black, with flames shooting out of its *ss!
And I want it right there! That's who I am!"
-- Unknown stand up comedian. I heard it in a radio clip, so if you can
tell me who this was, please do.
Noel L Yap wrote:
> Let's put it another way:
> cvs edit file
> // modify file
> cvs unedit file
> cvs ci file
>
> is exactly the same as:
> // modify file
> cvs edit file
> cvs unedit file
> cvs ci file
>
> which is exactly the same as:
> // modify file
> cvs ci file
>
> "cvs unedit" in no way removes the "checkout" (this definition is new to me if I
> understand you correctly). My proposal makes it very clear what version you'll
> wind up with after "cvs unedit" (as opposed to the current implementation
> which'll give you the version at the time of "cvs edit").
>
> Also, "cvs edit" and family are communication media. They should not be
> changing files on you. There are other CVS (and non-CVS) commands for this
> purpose.
>
> So, is your problem with the proposal that someone might accidentally commit a
> file that's been uneditted? Or that someone would usually expect a file that's
> been uneditted to be an unmodified version of the file?
>
> I don't understand the second part of your question, but I'll take a stab at it.
> My proposal prevents data loss (except maybe that CVS's backup mechanism only
> stores the last copy of a file). Nothing gets changed after "cvs unedit". If
> the file accidentally gets committed, it can always be rolled back (by
> committing the older version of course).
>
> Noel
>
> [EMAIL PROTECTED] on 04/04/2000 01:48:10 PM
>
> To: [EMAIL PROTECTED]
> cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Re: "cvs release" wishlist
>
> The implication being that wanting to keep the file checked out upon unedit is
> the
> desired behavior for the majority of users the majority of the time (otherwise
> saving the changes is also only a two step process) or that CVS's defined
> default
> behavior should never contain the possibility of data loss?
>
> Derek R. Price
> CVS Solutions Architect
> 303.554.8291
> [EMAIL PROTECTED]
> http://alumni.engin.umich.edu/~oberon/resume.html
>
> --
> Cynic: n. Someone who smells the flowers and looks for the casket.
>
> Noel L Yap wrote:
>
> Oh yeah, another view (ie reply) to your question would be: "cvs edit"
> and
> family is meant to be part of a communication medium. "cvs edit" tells
> others
> you are modifying the file and you plan to commit those modification.
> "cvs
> unedit" tells others you've changed your mind and you'll no longer commit
> those
> modification (if any).
>
> Also, I do plan to make yet another patch, "cvs ci -c", that'll check
> whether
> the committer has valid edits on the files to be committed before going
> through
> with the commit. So, in your scenario, if the user did "cvs ci -c -mtest
>
> myfile.h", the commit would abort (of course, for optimal performance the
> user
> really should have "commit -c" in his/her .cvsrc file).
>
> Noel
>
> Noel L Yap wrote:
>
> > Yeah, what's wrong with that? With cvs-1.10.8, "cvs update -C" will give you
> a
> > clean copy of the file provided you don't run into any of the merge bugs. If
> > you do run into those bugs, you can always revert back to the standard "cvs up
> > -r <base-rev> file >file" to get a clean copy.
> >
> > Yes, it'll now be two separate steps (one to clean the file, one to unedit the
> > file). The alternative is to make "cvs unedit" interface more complicated by
> > giving it three more options (one to check for modification, one to force the
> > unedit without unmodifying, and one to unedit and unmodify the file). If you
> > don't like the two step deal, you can always write a wrapper around cvs, but,
> as
> > of now, there is absolutely no way (without manually going into the admin
> files
> > or kludging a way (eg "cvs edit" the file again)) to unedit a file and keep
> all
> > modifications.
> >
> > Noel
> >
> > [EMAIL PROTECTED] on 2000.04.03 20:18:31
> >
> > To: [EMAIL PROTECTED]
> > cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> > Subject: Re: "cvs release" wishlist
> >
> > Hmm... doesn't that mean that:
> >
> > cvs edit myfile.h
> > [change myfile.h]
> > cvs unedit myfile.h
> > cvs ci -mtest myfile.h
> >
> > Would cause changes to be checked in?
> >
> > Derek R. Price
> > CVS Solutions Architect
> > 303.554.8291
> > [EMAIL PROTECTED]
> > http://alumni.engin.umich.edu/~oberon/resume.html
> >
> > --
> > You can lead a horticulture, but you can't make her think.
> > -- Janis Joplin, when asked to use the word "horticulture" in a sentence
> >
> > Noel L Yap wrote:
> >
> > > I can't help you with the first part of the request, but I have been
> planning
> > on
> > > working the second part.
> > >
> > > "cvs -Q release -d" will force the removal of everything except when there
> are
> > > files that have been "cvs edit"'ed and modified. Currently, there's no way
> > > around the interactiveness of "cvs unedit" (which "cvs release" eventually
> > > does). I've been planning on fixing this part of "cvs edit"/"cvs unedit".
> My
> > > proposal is to have "cvs edit" create a backup of the file (via the usual
> > > methods) and "cvs unedit" not to unmodify the file. This way, the sole
> > > responsibility of "cvs unedit" would be to notify watchers about the action.
> > >
> > > Of course, I haven't started on this patch yet, but I do expect it to be my
> > next
> > > CVS TODO (I might have something within a couple of months).
> > >
> > > Noel
> > >
> > > [EMAIL PROTECTED] on 2000.03.31 18:03:06
> > >
> > > To: [EMAIL PROTECTED]
> > > cc: (bcc: Noel L Yap)
> > > Subject: "cvs release" wishlist
> > >
> > > Greetings!
> > >
> > > When our build tool recognizes that someone has removed a CVS module from a
> > > build area, I had planned to "cvs release -d $module" to remove it from the
> > > build area and then do a "make clean" everywhere to make sure I had a clean
> > > build area.
> > >
> > > I was bummed to find out that 'cvs release' doesn't take a module
> definition,
> > > but a DIRECTORY. I would think if I could checkout a module, I would be
> able
> > > to remove a module. Even better, a "-f" option to force the removal even if
> > > there are locally-modified files would make this whole thing much more
> > > automatable.
> > >
> > > Does this sound reasonable? Possible? Desirable?
> > >
> > > :)hal mahaffey
