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 email@example.com.
Eric, > 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 or cvsnt, so I don't see a lot of benefit in writing new eclipse clients, mac clients etc etc. It's just wasted effort. 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? 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... > > Thanks, > > Eric > >