[cvsnt] Re: cvsnt patches/improvements

[Tony Hoyle]

On Tue, 23 Sep 2003 13:36:44 +0200, Michal Kara <lemming at is.cz> wrote:

>1) CVS keeps the information whether the file is edited or not in 
>Entries.Extra. I know it is not reliable (its just a hint), but it is 
>very useful - user can see in GUI (e.g., WinCVS) which file he has 
>locked. The other use is mentioned below (commit -e).

I'm not sure how useful that is.. It'd probably be wrong 95% of the
time and might lead people to expect it to be correct in some way
(leading to many bug reports I'd have to argue over) - 'cvs editors'
does the job and really is the only reliable method.

Of course if you have the edit that information is already stored in
the sandbox, so you know that info anyway.

>2) edit -b to not make backup copy on edit. This prevents using a lot of 
>space when user locks many files. unedit then doesn't restore the file, 
>but I consider that no issue.

OK

>3) update -L - makes backup of the file, does update and puts the backup 
>back. I.E., discards changes made in the repository copy. Dangerous (as 
>well as -C), but has its use when someone mistakenly changes file in the 
>repository, so you don't have to do this process by hand.

That's just *asking* to be abused.  I don't see how someone can
'mistakenly' change the repository, since the commit will fail if the
file is edited (provided everyone is forced to use commit -c eg. by
using a cvsrc file).   If it has changed it's up to you to to a manual
merge on the data otherwise there will be loss of information.

>
>4) commit -e - commits only files marked in Entries.Extra as edited. 
>Useful when something touches files you didn't really change. In 
>conjunction with -c prevents commit errors.

More explanation needed here...  If a file is modified it should be
committed.  If it's a generated file it probably shouldn't be in CVS
in the first place.  I'm not sure what you mean by 'touches files you
didn't really change'.

>5) commit -E - keeps file(s) edited after commit. Useful when you need 
>to keep your files locked - you don't have to remember which files are 
>"yours".

Not sure about this - it encourages bad practice...  The only reason
to do edit on a file is if you intend to edit and commit it.  Once you
have committed it then you are stating that you have finished editing
it.  This then gives the opportunity for other people who have been
waiting for you to finish (one of the reasons locks are so bad) to get
their chance.  The last thing you want is to allow people to hold onto
locks indefinately.

>   I have also patched WinCVS to be able to use these improvements and 
>to display which files has user locked (edited). We use patched CVS & 
>WinCVS for about two months in our development team and it seems to be 
>stable. But I need to put these changes into cvsnt first, before trying 
>to convice WinCVS people :-)
>
>   So I want to ask a few questions:
>
>a) Where should I send the patch(es)?

Add them as separate attachments to the bugzilla database (separate
bug per item preferably).

I'd take item 2 and possibly 1 (with modifications - it should only
ever hold data about local edits as a hint for WinCVS... attempting to
find out about other editors this way is too misleading to be useful).

3 isn't going to happen... 4 & 5 sound like needless bloat but I'm
open to persuasion.

Tony