[cvsnt] Latest updates

[Tony Hoyle]

cvsnt 2.0.42

Unstable test release.  Please stress this but not on production servers as I 
expect a failure or three.

It's not go everything in I want but holding back on a release for too long 
isn't a great idea - I lose my best sources of testing/criticism.

I intend to get this reasonably stable then code freeze and get the 
documentation up to scratch.  It's difficult to estimate a timescale - if I'm 
called away for 'paid' work It'll obviously take longer.

* Make fat32 behave better (should use vaguely the correct time now).
* Tunnel the executable bit using ACLs.  This allows a Unix client to commit
   executable scripts and have the bit preserved by NT CVSNT.  Also an NT
   client gets these bits set - cygwin can interpret them (although I don't
   expect my version to be the same as the cygwin one... it should be pretty
   close though).
* Try to preserve the drive letter case for clients (WSAD compatibility).
* admin -kc to force reserved edit on certain file types.
* Use username/password in HTTP proxy if available.
* Faster lockserver.  This uses some of the tricks I used in the devel version
   - it's not as fast as that version but is pretty good.
* Default cvswrappers entries.
   Specifically, the following are considered to be binary by default:
   gif, pdf, bmp, jpg, jpeg, png, exe, dll, so, a, pdb, lib, o, res, class,
   ogg, mp3.
   I considered adding doc to the list but it's a bit too generic (text files
   are often named doc too).  Any other suggestions welcome.
* cvswrappers parsing fixed.  You now don't have to use -k 'b', just -kb will
   do.  You'll also get a warning if there's an error, rather than the entry
   being silently ignored.
* modules2 has been rewritten (much simpler now) after feedback from users.
   It now works correctly if you overlay a virtual directory on top of a 'real'
   one.
* rename functionality.
   This is my favourite feature :)  It's only about 90% there (there are some
   more 'smarts' to add, and I haven't dealt with branch merges yet) but is
   usable now and it'd be good to get feedback on it.

   basically the command is 'cvs rename file1 file2', followed by a commit of
   the directory.  File renames are held at the directory level so just
   committing a file doesn't change anything... slightly counterintuitive until
   you're used to it but there are good reasons it works this way.

   If you haven't committed a rename it's held locally, and layered on top of
   the checked out directory.  If someone commits a new revision to a file
   you've renamed then you should get the update correctly.

   It's possible to do something like 'cvs rename a b / cvs add a / cvs commit'
   and in this case the 'new' file a is distinct from the 'old' file a (it is
   given a unique name in the repository).  This also means that RCS filenames
   may not be the same as checked out filenames... I predict problems with
   at least WSAD and possibly others.  I'll try to iron out as many as possible
   though (status and log already show the 'fake' filename).

   Branches should work and it's OK for a file to be called one thing in one
   branch and another thing in a different branch.

   You can rename across directories.  You can't however rename the directories
   themselves.  This is for client compatibility - I can find no way to make an
   existing client handle the rename (short of making it delete and recreate
   everything in it, which is a bit drastic).  I'm working on this though.

   At the moment directory version changes are silently tracked, but the
   optimisations available from this aren't implemented yet (the server should
   be able to track the rename of a modified file - at the moment it just
   generates a conflict).

   The directory version is held in the CVS/Tag file.  I don't think anything
   tries to parse this (beyond displaying it) but testing with various clients
   is a good idea.  Let me know of any problems.

Tony

-- 
Te audire no possum. Musa sapientum fixa est in aure.

Tony Hoyle <tmh at nodomain.org>  Key ID: 104D/4F4B6917 2003-09-13
Fingerprint: 063C AFB4 3026 F724 0AA2  02B8 E547 470E 4F4B 6917