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.
On Tue, 07 Apr 2009 20:04:42 +0000, Tony Hoyle wrote: ... > Crucially EVS is *not* a new version control system. It will be > whatever you want it to be. It can be CVSNT, or SVN, or TFS or > (potentially) Git. Or all of them at once, if you want. There isn't enough coffee in the universe to do that. To make that work you'd need a way to translate whatever your storage is into a git repository, and to be able to accept it back (in another repository). That and the way svn merge tracking works (or rather, does not), can simply not be made to work for the general case. It is possible for specific use cases, as git svn demonstrates, but even that breaks for svn usages 'out of the ordinary', and in presence of svn merge tracking. So, in order to make it work you will need to restrict to specific use cases, and that will exclude everyone not on those use cases from migrating to EVS. EVS seems to be somewhat like Microsofts CLR, a common denominator. But they don't need to be able to translate any CLR program back to every CLR-based language; but you need to to satisfy all the clients, with everything every other client may have produced. (git and the other DVCSes are hard in this part, because they aren't really clients but want to hold their own copy of the whole repository.) It may be possible to have one EVS-with-former-svn-repo, and one EVS-with-former-git-repo, but I thing a generic bridge is impossible. If it weren't, the VCS were actually semantically the same, and they very definitely aren't. Alone the way how we work(ed) with cvsnt *cannot* be represented in git, because there merges always take the whole repository. No partial directory or file merges -- the latter also makes migration to svn hard. And you *need* to represent it since that is how the git 'client' talks. Andreas