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