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 B. wrote: > 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. That's probably not needed. As Arthur said it's just duplication of effort as there are lots of really good clients out there, and we can support some of the more advanced stuff via the web interface. > 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? Personally I don't see these as conflicting. The whole point of EVS is it's flexibility - if someone has an EVS server and one of the programming teams want to switch to 'CoolVersioningTool' then we just write a translation layer for that tool and they carry on working. The data doesn't move and the server stays where it is, doing its job. So changes in the landscape and 'VCS of the month' really aren't an issue - because support for a particular protocol doesn't mean throwing out the system and starting again, merely implementing the new support. This keeps IT happy, since they have only one server to manage, and the developers happy, because they can use their tool of choice. It also gives each system the advantages of the other one - eg. if you can't rename in your chosen CVS client, mount the repository, rename the file there, then just update in your client again. If system A has a feature you'd like to use but you normally use system B, checkout using system A, do whatever you need, and all the changes are reflected correctly in your original system, automatically. Tony