[cvsnt] Betr.: CVSNT to CVS

Andreas Krey a.krey at gmx.de
Wed Apr 8 08:52:47 BST 2009


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


More information about the cvsnt mailing list