[cvsnt] Betr.: CVSNT to CVS

[Tony Hoyle]

Andreas Krey wrote:

> 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.

Not at all.  It merely needs to be pretend to be git.  It's probably not 
even that hard, provided you can export something that looks like a git 
repository, and accept that back.

Looking at the techincal docs I can't see anyting particularly 
challenging there (in fact as the client does all the work, it's 
actually a lot easier than some systems).  There doesn't appear to be 
any docmentation of the native protocol, but that's not unusual these days.

> 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.

evs is *already* a generic bridge.  It works.  There are rough edges, 
mostly due to time constraints, but the technical barrier has been sorted.

And yes the are all the same, at heart.  That's the depressing thing 
about it.. they all go off writing new ones instead of improving what's 
there already and end up with something that is basically the same thing 
with a new skin on it.

Sure, you can talk about client/server versus distributed (which is 
really server/server), or DAV vs something else, or having repository vs 
file versions.. but those aren't fundamental differences when you break 
it down to what you're doing.  The reason for that should be obvious - 
you're storing end user actions, and those actions don't change.  A 
rename will always be a rename, a file modification will always be a 
file modification.

Are there compromises in evs?  Yes.. tagging with the cvsnt client 
doesn't *quite* have the same semantics for example.  SVN doesn't 
support unicode, or renames (their rename command is just a 
copy/delete).  TFS is, well, TFS... Doesn't matter to us - since all 
clients are equal if someone wants to do something not supported on one 
clent they just use a different one.

> 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.

That's an implementation detail.. I heard much the same when we talked 
about supporting SVN and CVSNT simutaneously.. they were supposed to be 
'too different'.

There's no fundamental difference between a repository merge and a 
directory/file merge in terms of what actually happens.  The only 
difference is the unit of change you're dealing with.  evs has more fine 
grained object tracking than any system currently out there (that I've 
seen) and at the same time can represent changes at the repository level 
   if required.  It was designed from the ground up to do that.

Migration to SVN is hard because it's SVN - The SVN server part of evs 
was 3 months of trying to work out why the hell they did it like that 
(and I'm still not sure I answered it).

Tony