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 Wed, 08 Apr 2009 10:28:16 +0000, Tony Hoyle wrote:
> Andreas Krey wrote:
>
...
> >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.
Waitaminute. You need to convert the full history that EVS holds into
a git repo, otherwise the git (client) users will complain because
a) the history isn't there and b) if you hand out partialized histories
the commits won't have their usual identities. If the git users aren't
able to pull from one another, why should they bother at all?
Also, as a git user I would expect to be able to pull from one EVS
repo and then push one branch into another EVS repo; and would
expect EVS to include in that branch any partial history that
was already there. To be able to do that means basically that
git commits (including history) can be converted 1:1 in both
directions ('bijective'), and that would mean that an EVS repo
*is* a git repo, especially with nothing more.
> 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.
Just branch out (in cvsnt) one subdirectory, start working in that
branch, and merge back a few (not all) files. The history you
now have in cvsnt cannot be properly represented in git (and possibly
neither in svn). You can represent the state of the files in all
commits, but what is missing is the correct merge tracking information.
As long as you don't bother with full merge support, there isn't
much of a problem, correct.
...
> evs is *already* a generic bridge. It works.
Between cvsnt and svn?
How do you map the trunk/tags/branches metaphor? How do you import
from svn when the used style doesn't match your way?
> There are rough edges, mostly due to time constraints,
It is my argument that the time constraints can't be lifted
if full interoperatility between cvsnt, svn and git clients
is to be achieved, especially on already-existing repositories
that did some strange things.
> but the technical barrier has been sorted.
I will believe that when I can freely merge from git and svn clients,
without either getting the jeebies.
> And yes the are all the same, at heart.
At heart all programming languages are turing-complete. That does
not mean that they don't have differences that are a) worth to
switch for and b) not even easily representable in other languages.
...
> Sure, you can talk about client/server versus distributed (which is
> really server/server),
I think this is the important part. DVCSes suddenly open styles
of collaboration that previously simply impossible.
...
> 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.
git doesn't store renames either; they conceptually just the store
the current state of the tree after each commit.
Also, svn:externals aren't anything elsewhere, as are git
submodules or cvs modules. There are some possible mappings
between each other, but none of them are the only possible
way of doing things, and doing the mappings at least requires
some project-specific configuration.
...
> 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.
I'm quite certainly not. I hardly use the svn client but instead
git svn, and being forced to occasionally use the svn client just
sucks.
And I think that's the point: Depending on how 'mostly' you support
the different clients, those that are used to that client (and server)
won't accept that, and rather stay with the current state.
> >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'.
Pfft. svn and cvs are almost the same, except for the stupid
tags-are-in-file-namespace idea. They both give you the advantage
that you can basically hide the actual history from the clients.
To interoperate with git you need to *give* them the full history.
> 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)
Looked into darcs? As far as I heard they can record variable name
changes as such.
> and at the same time can represent changes at the repository level
> if required. It was designed from the ground up to do that.
That's the problem: git was designed not to do this.
Did you design the storage model in a way that makes it possible
to actually work distributed? That is, do a branch here, and later
push that branch to the other server where other commits have already
been done?
That's the actual wonderful thing about git and the other DVCSes:
I would just clone, say, the cvsnt repo, and work on some features,
and I can do so under version control. When I'm done I can just tell
you to pull it back -- no need for committer status or nothing.
(I had the same problem just yesterday under svn. Someone needed
a little modification and had it in his sandbox but wasn't allowed
to commit. Now he needed to find someone to grant him access, or
to carry around that file to a sandbox whose owner can commit. In git
he could just commit it locally and tell someone with commit rights
to the official repository to pull his change and push it to central.
Without even losing the commit attribution.)
> 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).
The way svn stores the merge info is simply broken, and I suspect that
also has effects on the client.
Andreas