[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 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.
>> If flags were added, there'd be a few unlesses for the "cvs unedit"
>interface.
>> It'd be more complicated.
>
>Yep, but many functionality is already there, it might just need "-f" to
>force the revert from backup.
Like I said, you would need at least two new flags. One to get the behaviour
you want, another to override it in case it's in your .cvsrc file.
>It doesn't matter if it's complicated, it must be USEFUL first of all.
The patch very useful to me the way I did it. Again, you're welcome to patch
the patch if you want.
>> If so, those side effects are highly documented and consistent (ie they're
>not
>> side effects).
>
>Since when "documented side effects" stop to be ones? They're still side
>effects.
The fact that they are documented /and/ consistent makes them not side effects
(ie predictable behaviour). Note also that the side effect of automatically
using a mangled backup won't be seen until "cvs unedit". This may not occur for
days or weeks or ... Such a side effect is horrendous. Users will constantly
be posting "cvs unedit" bug reports due to their actions (which they most
certainly will have forgotten by the time the "cvs unedit").
>> No they can't. What part of "\"cvs edit\" saves a copy of the file the
>way it
>> was at the time of \"cvs edit\"" don't you understand? Or, can you
>explain how
>> you'd go about using timestamps to figure out if something has happened to
>the
>> backup?
>
>OK, forget about the timestamps. Just:
>1. make it readonly.
OK, I just checked this. It currently doesn't make the backup read-only. I'll
change this (unless I find that I had a reason not to).
>2. rename it a bit to avoid the cinfusion, especially change the extension
>so the grep tools will no more pick it up. THe way to rename with the
>revision number appended to the name sounds as a perfect solution.
It's named .#foo.c right now (in my patch). I don't see why your grep tools
would pick that up. I'll look into tagging the revision number on the end of
it, but it might affect other commands' backups (IMHO, this is A Good Thing,
anyway).
>This two steps are simple, consistent and USEFUL, they don't breake current
>behaviour and they solve most problems with the backup copy.
OK.
>> I haven't been able to figure out a way to see if there is a connection or
>not.
>> Perhaps someone can help out here? I've seen other occassions to know the
>> connectability status.
>
>You can just attempt normal connection and wait to see if it will fail.
I haven't seen an easy way to do that with the CVS code the way it is. If you
can suggest exactly how (ie source code) that can be done, I'd appreciate it.
>> From what I've seen in the past, you seem to have been hacking WinCVS. If
>this
>> is true, you should be able to easily (since the interface is so simple)
>hack
>> WinCVS to do most of what you want.
>
>Sure I can. But I would not for example attempt to put the code with
>hardcoded setting to access my company repository into the public. I patch
>to my needs but FIRST of all I will think how common problem and how generic
>solution is.
I don't understand. The patch I posted solves a set of problems (but perhaps
not yours). I, in no way, hardcoded anything specific to my company. The
solution is generic. What I'm saying is that you can patch WinCVS to account
for the patch (you know exactly what comes out of "cvs edit", you can therefore
change the WinCVS unedit to suit your needs).
>> If you feel otherwise, don't use my patch (or patch it up some more).
>> Seriously, though, none of the others have jumped in 'cos they don't use
>"cvs
>> edit" and "cvs unedit". I think I'm the only one who does who also wants
>to
>> maintain the CVS philosophy of keeping the tool simple.
>
>Hm... the others did jumped, Most if not all WinCvs users are using
>edit/unedit all the time since that is how the tool works best.
Yes, but "cvs edit" and "cvs unedit" NEVER worked the way you or the others
expected it to. WinCVS forces the behaviour you see now by wrapping CVS.
That's a perfectly good solution to your problem.
>They are
>complaining about your patch, "hear the voices" and maybe revise your patch
>a little bit?
I don't think so. They're complaining that my patch brings to the surface the
true behaviour of "cvs edit" and "cvs unedit". They don't like that behaviour.
The only way to fix it is to wrap it. A patch to CVS to "fix" it (I really
don't see a problem) will make CVS much more complicated (just look at your
suggestions to fix it).
>Onestly I was hoping that one day we would support RCVS at
>least to get 'csv edit -c' functionality and kick off the admin locks. Try
>to keep RCVS more/less consistent with the CVS...?
That's /exactly/ what I'm aiming for. Unfortunately, you guys seem to have a
different idea of what CVS is than I do. Perhaps you should look at the code
yourself to see how difficult (or even impossible) it is to do what you want
(specially given that "cvs edit" and "cvs unedit" should work offline).
Noel
PS
I might've broken the offline behaviour in the patches since I have no way to
test it. If someone out there can, it'd be very much appreciated.
This communication is for informational purposes only. It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan & Co. Incorporated, its
subsidiaries and affiliates.
