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.
"Arthur Barrett" <arthur.barrett at march-hare.com> wrote in message news:fod1to$od2$1 at paris.nodomain.org... >> So Evs (the server) can support all of the above easily. The 'client' - >> cvs, cvsnt, or the evs client - may not do. cvs and cvsnt have hard >> limits on the way they represent tags and branches, and wouldn't even be >> able to checkout a tag name with a space in it, for example. They also >> have no intrinsic support for tags with extended characters and are >> liable to render them as junk. > > I suppose we could perform some basic transliteration in the compatibility > layer (basically replace any punctuation, white space or 'extended > character' to an underscore, and truncate the length if required) but then > then danger is that several tags/branches may appear identical when they > are not. Ahhh - the joys of needing to maintain backwards compatibility. I can understand what you are saying. I am definitely happy to hear that by design EVS can handle this by default, and that the issue boils down to backwards-compatibility with older CVS clients. 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. 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