[evs] Does EVS remove some of CVS limitations?

Arthur Barrett arthur.barrett at march-hare.com
Thu Feb 7 04:25:54 GMT 2008


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




More information about the evs mailing list