Re: [ANNOUNCE] git-as-svn: subversion frontend server for git repository

From: Marat Radchenko <marat@slonopotamus.org>
Date: Sep 9, 2014, 18:57 UTC
Message-ID: <20140909185711.GA14554@seldon>
In-Reply-To: <xmqqy4tsloxs.fsf@gitster.dls.corp.google.com>

On Tue, Sep 09, 2014 at 09:49:03AM -0700, Junio C Hamano wrote:

Show 9 quoted lines

> Marat Radchenko <marat@slonopotamus.org> writes:
> 
> > Some time ago I complained [1] about troubles using Git
> > on a project with high ratio of non-programmers.
> > ...
> > Then, a lost'n'forgotten git_svn_server [4] was found.
> > ...
> 
> Interesting.

Actually, no. As I said, git_svn_server made several ineffective architectural choices. It can be viewed as a proof-of-concept work though.

Show 7 quoted lines

> > Current limitations:
> > ...
> >   * You must not do 'inverted merges'. Old HEAD must be reachable from
> >     new HEAD by first-parent traversal.
> 
> I am not sure what you mean by this to properly assess how
> significant this limitation is.  Care to draw a simple picture?

SVN doesn't support nonlinear history (except merge-info crutch).

Thus, we only expose "main" history line to SVN where "main" means "reachable through first-parent traversal from branch tip".

To keep SVN history consistent, commits that once became visible to SVN have to remain visible. This limitation will be removed when git-as-svn gets persistent storage and will be able to remember what *was* main line.

Imagine you had following history:

--- time --->

A -- B -- C

Now you merge (via Git) a feature branch:

A -- B -- C -- G
 \            /
  D -- E --- F

For SVN, history will look this way:

A -- B -- C -- F

We might introduce merge-info support for this one day.

And now the *bad* case. You have the same initial history but do *inverted merge*:

A -- D -- E -- F -- G'
 \                 /
  B -- C ---------/
       ^
       |
    Previous branch tip

That's where things brake because for SVN, history transforms from

A -- B -- C

to

A -- D -- E -- F -- G'

And all users who checked out revisions B & C get their working copies screwed.

This also means that push --force also must not be performed.

Quoting my initial post [1] about inverted merges (you might call them "merges with swapped parents").

Show 31 quoted lines

> I call it "swapped/reverse merge problem".
>
> In short:
> 1. Hack, hack, hack
> 2. Commit
> 3. Push, woops, reject (non-ff)
> 4. Pull
> 5. Push
>
> The root of evil is step #4 that creates a merge commit with "swapped" parents - 
> local commits become first parent, remote commits become second. If one would want to 
> make proper parent order, he would have to: 1. git fetch
> 2. git checkout origin/master -b tmp
> 3. git merge master
> 4. git push
> 5. git checkout master
> 6. git merge origin/master
> 7. git branch -d tmp
> 
> And all this branch dance produces exactly the same commit (content-wise) as simple
> "pull, push" sequence with the only difference in parent order. And things become
> even worse if comeone pushes more commits to remote repo while you perform this
> dance.
>
> We can't expect all developers (especially, designers and artist) to do it. They
> don't want to use branches and just work on mainline. This is especially important on
> early development stages when new features (that designers' work depends upon) are
> added every day.
>
> Additionally, many git-related tools depend on first-parent convention and show wrong
> graphs/diffs.

[1] http://marc.info/?l=git&m=139866660018802