[cvsnt] cvsnt patches/improvements
Michal Kara
lemming at is.cz
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
More information about the cvsnt
mailing list