[cvsnt] cvsnt patches/improvements

Tue Sep 23 12:36:44 BST 2003

   Hello!

   We use CVS for binary files. However, CVS is not much suited for this 
task, so I have made a few minor improvements, which enhance the 
reliability of CVS in such use.

   Main problem with binary files is that you can't merge changes. So 
you must aim for strict locking.

   The changes I made mostly add new switches. As far as I know, they 
don't break anything:

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).

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.

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.

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.

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".

   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)?
b) Which added features are acceptable and which are not (and why)?

						Thanks,
						Michal Kara