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.5.04 (Zen) Build 3125 (RC8) You can download this release from: http://www.cvsnt.org/wiki/Download Fixed in this release: ------------------------ 5312 release -y option ignored 4713 Auth fails from linux with sspi when no domain specified 5076 mini.so crashes cvslockd on 64bit systems 5283 Crashes when combining newly added file with rename in one commit 5237 cvs co -p -r CVSNT_2_0_x 'directory stack overrun' on debian 5307 Audit doesn't record correct info columns 5308 Oracle NLS support does not work on linux 64 bit 5316 CVSNT: Debian build (thanks to Andreas!) Fixed in previous release candidates but not previously mentioned: 5328 HQX fixes for OSX 5329 Support bi-directional merges (inverse merge) I'll release a summary of all the bugs/features since 2.5.03 when 2.5.04 is released stable. Latest documentation: ----------------------- http://www.cvsnt.org/manual_testing_2.5 Description: -------------- RC8 was released today - and RC8 is the second that includes binaries and testing on non-windows. This RC is required because the last RC used a newer a version of libxml2 than most current operating system releases support (redhat/suse/osx etc) - basically the RC7 worked on RedHat5 and windows and that was all and we decided this was not really good enough. Remember that 2.5.04 RC6 and higher do change the audit database schema from previous 2.5.04 releases which in turn were different to 2.5.03 releases. The 'upgrade' button should smart enough to handle this - run the upgrade-1 then run the upgrade-2, but I may be wrong. Also 2.5.04 has a different API to 2.5.03 which means that custom ActiveScript and C++ triggers will need to be updated to the new API - but this is not particularly new with this release. This RC is close to 'stable', but I really need feedback on: * works on RHEL4/RHEL5/RedHat9? * works on OSX Intel? * works on Debian/Ubuntu? * does the oracle audit work? * upgrading from 2.5.03 audit? * works on Vista? * works on Vista x64? * works on W2008 x64? There will be at least one more RC before 'stable'. Immediate Forward Plan (2.5.04 stable/EVSCM RC): ------------------------------------------------- Due to dependency changes with 2.5.04 from 2.5.03 we are reviewing/testing which platforms can be supported on 2.5.04. The primary dependency change is libxml2. This is the main 'purpose' of this build. I'll be working on some audit "migration" testing, looking at which platforms I'll build the oracle support for (this RC probably only has Oracle support in HPUX and Windows), some minor GUI fixes and will also merge in changes from the commercial 'cvsdiag' while I wait for you all to complete testing and send in feedback, but I'd like to release 2.5.04 stable in the next couple of weeks if I can find the time and I get enough feedback... A new EVSCM beta will be released around the end of July, we'll then hopefully concentrate on writing a 'migrator' so people with existing repositories can try 'upgrading'. Forward Plan: -------------- EVS client can work with CVS/CVSNT servers, so in the future we may start encouraging client users (particularly windows users) to use that instead of CVSNT. The profile of a person who will run CVSNT server versus EVSCM server are very different (you need a database and a very modern OS and computer to run EVSCM), so trying to 'push' CVSNT Server users to EVSCM seems counterproductive to me (for now anyway), however right at this point in time I think that CVSNT server has reached the pinnacle of it's evolution. Certainly there are things that people want CVSNT to be able to do, however those requirements also indicate that those people should be switching to EVSCM (ie: they are large scale/high end requirements of large organisations/teams). Work will begin on 2.5.05 almost immediately, however those changes are almost entirely aimed at our commercial support requirements and would not be of much use to anyone else. I will remove default support for ":ext:" (should be ":ssh:") and ":local:" (though I'll probably leave some way to re-enable them), and I'll update the included version of pcre to something a little more recent. I do have some really interesting feature patches that have been submitted that unfortunately are based on CVS 1.11 or 1.12 - but I'd like to have a go at incorporating them into CVSNT at some stage (eg: using the audit database for tag operations rather than the RCS files), but budget constraints pretty much precludes any of that, and again, EVSCM is a better solution for the types of problems the patches solve anyway. The latest build of CVS 1.12 includes a new 'sign commits' feature that we've been asked to support at least in the CVSNT client, and does occasionally come up as a feature request for the server. Unfortunately the feature as implemented in CVS 1.12 seems to have an interdependency with several 'offline' features committed at the same time which we are reluctant to add (basically your sandbox is doubled in size because there is a copy of every file checked out in the hidden CVS directory). Provided we can find a way to support this only when the user wants it then we'll try and get that added - however it'll likely be added to EVS client not CVSNT client. Ideally we'd like a signed commits feature that can be used with EVS and CVSNT server that doesn't have this dependency, but again - we have lots of ideas and not enough resources. So in short - please download the beta of EVSCM (particularly the client) and do some testing, and pester your line manager to either allow you some time to contribute back to the EVSCM/CVSNT project, or to purchase a copy of CVS Suite (with the CVS Suite Studio and Microsoft Visual Studio 2005/2008 integration) or a CVS Professional Support Subscription (1+years) so that we can continue to facilitate the deveopment of EVSCM and CVSNT on your behalf. Zen: ----- (These notes are largely unchanged from RC7, except for the addition of references to newsgroup posts) Build 3055 is (hopefully) the last RC of the CVSNT 'Zen' project. This is a 'feature' release and apart from a few exceptional 'bugs' does not fix any 'bugs' in the previous 2.5.03 'Scorpio' project. The reasons for this are: * there have been almost no bug reports on the newsgroup about Scorpio * the Zen project was always about adding specific features that were often requested The CVSNT project got started many years ago because there were features that the developers wanted in CVS 1.10 but the CVS 'charter' prevented having these changes applied to the CVS source code repository - basically the charter says that if any developer rejects the patch then it wont be applied, and with all the developers active on the project there was always bound to be one that would reject a patch for what can be primarily described as 'philosophical' reasons. The CVSNT project does not have such a charter and we try to ensure that we don't reject ideas for features just because some developers don't agree with the need for such a feature - though we do like to ensure that new features are 'optional' - ie: you don't have to use them if you don't want to. This is the first CVSNT development I can recall where the entire devlopment features were things that Tony and I really didn't think were *needed*. This partly explains why this release has been a long time coming. We do however understand that other people do find these features important so we've worked hard to bring them to you. The features that we really DID think were needed just could not be supported by the current generation of the souce code, hence why most ofour effort has gone into EVSCM (previously known as CVSNT 3.x). The particular features that Zen set out to address are: 1. multi site repositories (multiple repository locations) 2. use of checksums on large files to improve WAN performance 3. trusted Windows DLLs - DLLs are signed and signature checked before loading 4. a single download that is easy for 'windows end users' to use 5. better statistics of project adoption 6. cvsnt server control panel support for Vista UAC * Items 1 and 2 are specifically to address some users belief that CVS will run faster if there is a local repository cache. After much analysis and discussion internally we cannot see any benefit for this since the CVSNT protocol was designed for telecommunications networks far slower and less reliable that what is available today. Secondly in hypotheticals about 'if we did do multi-repos' - we could not see any benefit in a quorum based system where the changes on onerepository are mulitcast to several servers simultaneously, since the quorum needs to be tracked and the 'excluded members' of the quorum are just as incapable of accepting patches as is a single repository shadow. The solution we have come up with is a 'master' repository and multiple shadows. If you like you can change which is the 'master' at any time you like. We have been using the 2.5.04 repostiory cache/shadow feature for quite a while internally and it works very well - and if you have largebinaries in the repo or your processes require 'fresh checkouts' rather than 'updates' then installng a shadow does improve performance. Changing your procedures to use 'udpate' would do the same thing and would have required 2 years less effort. We cannot stress enough just how unnecessary repository replication and caching is for 99.9% of organisations - if you are experiencing multi site performance problems there are probably much 'better' ways to fix it that using repository replication and caching. If you want more info on the repository replication stuff please see the previous newsgroup posts: http://www.cvsnt.org/pipermail/cvsnt/2008-May/030637.html And http://www.cvsnt.org/pipermail/cvsnt/2008-May/030642.html And http://www.cvsnt.org/pipermail/cvsnt/2008-May/030653.html And http://www.cvsnt.org/pipermail/cvsnt/2008-May/030655.html And http://www.cvsnt.org/pipermail/cvsnt/2008-May/030659.html * Item 3 solves two problems on windows: 3a) solves 'DLL hell' where CVSNT would fail to run on some systems because it would find the wrong version of a DLL (eg: libiconv) 3b) increases security - users of the builds from march-hare.com web site can be sure that the application .exe and .dll signatures are valid and CVSNT will not load an unsigned protocol or trigger. If you build your own windows DLLs then only a warning will be issued instead of the application aborting (see (#define COMMERCIAL_RELEASE). * Item 4 is simply to create our own MSI that includes all the goodies a typical windows client user is looking for: WinCVS, TortoiseCVS, WinMerge, CVSNT - we also include a 'free' edition of our WorksaceManager/CVS Suite Studio which is a lot like a 'simple' version of WinCVS that uses TortoiseCVS for much of the client functions. We've also added a window to most gui dialogs to show the recent newsgroup postings so that people are encouraged to read the newsgroup and contribute to discussions. * Item 5 is to give us more ammunition when advocating for the use of CVSNT. We already track how many downloads of CVSNT we get, and SourceForge track the downloads of CVSNT as a part of TortoiseCVS and WinCVS - 1.4 million annually last time I added them all up. However that does not tell us if they are ever installed, and how they are used. So the client and server installers now attempt to notify us of an install (no IP address is kept, though we do a geoip lookup using maxmind data to determine the country). If you install the server then the server process keeps statistics about how the server is performing (number of users, process duration etc) which an admin can see by looking at the control panel. The statistics which are collected are then sent to our server weekly so we can 'see' how the CVSNT servers are performing in the real world (again: no IP address is kept, though we do a geoip lookup using maxmind data to determine the country). These statistics will let us post information on the web site and/or newsgroup about how many CVSNT servers are out there 'in the wild' and how they perform. If your performance characteristics are significantly worse to the ones we are publishing then you know you can improve things. I cannot stress enough how important obtaining this information is to the future of the project. * Item 6 is to allow the gui control panel on vista/w2008 to work under the UAC security. Note: all versions of CVSNT server and client run fine on Vista - it is only the GUI control panel which is improved for vista in 2.5.04/Zen. Regards, Arthur Barrett