[cvsnt] Betr.: CVSNT to CVS
tony.hoyle at march-hare.com
Wed Apr 8 10:28:16 BST 2009
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
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
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).
More information about the cvsnt