[EMAIL PROTECTED] on 2000.07.20 14:14:21
I think perhaps you are speaking as a cvs developer here not a cvs
user. To me "cvs unedit" has a closer meaning in english for
reverting files than "cvs update". But I guess the "cvs update -C"
isn't technically reverting files. Its updating them
[EMAIL PROTECTED] on 2000.07.24 02:10:47
Hm... If unedit will not modify the existing file than what is the use of
backup?
The same purpose it serves for "cvs up" and other CVS commands -- for the
user
to use at his/her discretion.
Well, so far that backup copy of the file was rather to
[EMAIL PROTECTED] on 2000.07.21 17:43:11
The interface to CVS with my patch is: "cvs edit" will save a backup
using the
standard naming conventions for backups. "cvs unedit" will not modify the
existing file. This is an extremely simple interface.
Hm... If unedit will not modify the
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
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.
For Developer Studio the problem is solved for you if you use CvsIn. It will
kindly warn you if you try to open the file which is in the "*/Cvs/Base/"
directory and
For Developer Studio the problem is solved for you if you use CvsIn. It will
kindly warn you if you try to open the file which is in the "*/Cvs/Base/"
directory and tell you not to edit it. So it is not important that the file
is writable - you will get the message box each time you activa
[EMAIL PROTECTED] on 2000.07.21 03:02:56
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
[EMAIL PROTECTED] on 2000.07.21 04:58:09
Personally I think I want Unedit to revert the file's changes. WinCvs and
CvsIn (well, cvs.exe in fact) gives an option to revert the changes or not
if the file has been modified. I would rather want some patch to allow me to
force the revert and not
Dear Noel,
When I first made this patch, I decided for two reasons not to add "cvs
unedit"
flags to revert or keep changes:
1. Flags complicate the interface to "cvs unedit".
?! What kind of argument is that? NOT having the flags complicates the
interface to cvs! Come on, all CVS commands
[EMAIL PROTECTED] on 2000.07.21 14:12:25
When I first made this patch, I decided for two reasons not to add "cvs
unedit"
flags to revert or keep changes:
1. Flags complicate the interface to "cvs unedit".
?! What kind of argument is that? NOT having the flags complicates the
interface to
Dear Noel,
The interface to CVS with my patch is: "cvs edit" will save a backup
using the
standard naming conventions for backups. "cvs unedit" will not modify the
existing file. This is an extremely simple interface.
Hm... If unedit will not modify the existing file than what is the use
[EMAIL PROTECTED] on 2000.07.20 07:44:23
Maybe we don't understand each other properly.
I've mostly used CVS through WinCVS. The default WinCVS setup uses
watches, wihich requires that you use "edit" to make the file writeable
before you edit it (all files are read only after checkout).
Noel Yap wrote:
The documentation is dead wrong. Instead of complicating the
documentation (by
describing that "cvs unedit" will revert the file back to the copy at
the time
of "cvs edit"), it's much easier to simplify both the documentation
and the code
(by saying that "cvs unedit" doesn't
[EMAIL PROTECTED] on 2000.07.20 12:25:36
Noel Yap wrote:
The documentation is dead wrong. Instead of complicating the
documentation (by
describing that "cvs unedit" will revert the file back to the copy
at
the time
of "cvs edit"), it's much easier to simplify both the documentation
and the
[EMAIL PROTECTED] on 2000.07.20 12:25:36
Noel Yap wrote:
The documentation is dead wrong. Instead of complicating the
documentation (by
describing that "cvs unedit" will revert the file back to the copy at
the time
of "cvs edit"), it's much easier to simplify both the documentation
and the
[EMAIL PROTECTED] on 2000.07.20 12:52:32
If it doesn't "unmodify" code, what is its purpose, then?
Exactly what the command is, "cvs unedit". It removes the edit from
the file
and notifies watchers of the action. I forget how I had it treat the
write bit
(in my patch).
Remember, "cvs
Noel Yap wrote:
[EMAIL PROTECTED] on 2000.07.20 12:52:32
If it doesn't "unmodify" code, what is its purpose, then?
Exactly what the command is, "cvs unedit". It removes the edit
from
the file
and notifies watchers of the action. I forget how I had it treat
the
write bit
(in my patch).
[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
Noel Yap wrote:
[EMAIL PROTECTED] on 2000.07.20 13:37:52
Personally, I would like to see some sort of module "revert"
command.
Currently, I can only revert a file at a time by doing:
rm file
cvs update file
"cvs up -C" will revert files back to the repository copy. This is
[EMAIL PROTECTED] on 2000.07.20 14:14:21
"cvs up" is the ideal place to do this, not "cvs unedit". Like I
said, "cvs
unedit" is to facilitate communication -- nothing more, nothing less.
I think perhaps you are speaking as a cvs developer here not a cvs
user. To me "cvs unedit" has a
Stephen Rasku wrote:
I think perhaps you are speaking as a cvs developer here not a cvs
user. To me "cvs unedit" has a closer meaning in english for
reverting files than "cvs update". But I guess the "cvs update -C"
isn't technically reverting files. Its updating them and throwing
away
You'd still be able to do what you want by using a wrapper
script or function.
Noel
[EMAIL PROTECTED] on 2000.07.19 09:01:36
To: [EMAIL PROTECTED]
cc:
Subject: Re: Base directory, in CVS directory
--- In [EMAIL PROTECTED], "Noel L Yap" [EMAIL PROTECTED] wrote:
Short answer:
Use
[EMAIL PROTECTED] on 2000.07.19 10:31:17
The change you describle does change the standard behaviour of unedit,
since the file no longer reverts to the original version. For what it's
worth: My opinion is that unless this is accepted by most CVS users, it
is probably your new behaviour that
[ On Monday, April 3, 2000 at 15:43:43 (CST), Win32 M$ wrote: ]
Subject: Base directory, in CVS directory
That is a great feature, but the problem is that it is the copy with the
exact same name as an original. Then, if I try to grep for the files
recursively in some directory, I will get
Hi Noel,
Short answer:
Use "find ! -path '*/CVS/*'" (if you're using gnu find). Otherwise pipe
the
output of find through "grep -v '/CVS/' (you might have to backslash the
'/').
??? Answer to what question? I asked three:
1. Are there any other people with similiar opinion;
2. Are there any
[EMAIL PROTECTED] on 2000.04.08 20:11:12
But the long answer is interesting:
Long answer:
I've come to think that the Base subdirectory is a broken design.
1. The copy stored in Base isn't really the version that was originally
checked
out, it's the version existing at the time of "cvs edit".
26 matches
Mail list logo