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.
Eric, Sorry - my previous reply got sent before it was finished... > I would guess / expect in that case that once EVS starts to build a > foundation base, and gains support in the community, we may begin to see > more native EVS clients that could bypass the compatibility layer and > communicate directly using native EVS APIs. Personally I'm not so sure about that. 99% of what people need to do on a day to day basis can be done using a legacy client like cvs and cvsnt, so I don't see a lot of benefit in writing new eclipse clients, mac clients etc etc. It's just wasted effort. There was a great article on the valuation of IT assets published in The Financial Times UK Edition 36,501 on Monday October 1 2007, and I believe the author will be releasing the complete whitepaper soon. Basically it talks about the lack of business cases for the benefit of software and also the business case for maintaining legacy assets. The costs of replacing software like CVS is astronomical and rarely worth it to the business, except perhaps that techie employees who like playing with the latest gadgets are less likely to leave that week/month for some other company, thereby reducing employee turnover. I think far more likely is that you'll 'existing users' use existing clients, and new users use the webdav interface (a bit like the clearcase dynamic view - you just mount http://server/myrepo/project/hello onto h: drive and edit away - each change is automatically versioned. Admin will be done through the web interface (including being able to go back and add meaningful comments to all those changes, thought I'd like to see some variation to the 'map network drive' feature that you could specify a change set, eg: mount http://server/myrepo/project/hello?bug=1234 instead ). As you've pointed out - the main reason to use a 'native' client would be to get UTF8 tag/branch names and descriptions etc - these are mostly administrative. > Speaking of which, is it of much concern is it that SVN seems to be > building such a strong following, seemingly stealing away users from the > CVS base? Or are you confident that EVS will be such a better, more robust > system that any SVN'ers will come back? One of the reasons why we changed the name to EVS was that it is really a completely different system to CVS or CVSNT. Hopefully SVN users who choose to migrate their server to EVS will not see it as 'coming back' but as 'moving again'. > I keep seeing more and more FOSS projects transitioning to SVN these > days. Has anyone given any thought to a SVN-to-EVS import function? I've > only ever seen CVS-to-SVN, but never the other way around... Yes it'll be done, but a CVSNT->EVS migration tool needs to be done first. Since SVN can have several different 'back ends' we couldn't go directly from the raw data to EVS, we'll need to use some sort of 'suck and spit' method. Thanks for bringing this up because it is something I keep forgetting to put on my lists... We are planning some things for EVSr1 so that an organisation using CVS, CVSNT or SVN can switch to EVS server with very little impact (or cost) to the organisation. Regards, Arthur