Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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