Re: native-git-svn: A Summer of Code 2010 proposal

[Avery Pennarun <apenwarr@gmail.com>]

On Fri, Mar 19, 2010 at 2:39 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Fri, Mar 19, 2010 at 19:32, Avery Pennarun <apenwarr@gmail.com> wrote:
>> - all those "extra commands" that git-svn supports are considered
>> backwards compatibility, even if they're absolutely obsolete because
>> of newer commands, and therefore will be very hard to justify getting
>> rid of
>
> I don't think this is true. The proposal is to implement
> git-remote-svn, which would allow _native_ interaction with svn
> repositories, so without using 'git svn'. It would allow 'git clone
> svn://example.com/myrepo' and subsequent "git pull"s from that svn
> source. Do you agree that makes (part of) your comments moot, or am I
> missing something?

I don't know enough about the proposal to comment on this part of the design.

I do know that where git-svn fits into git's UI has not been the
problem for me or my co-workers; we can learn some weirdo syntax if
needed.  Things like branching and merging, and git-svn redownloading
the same stuff 100 times, and oddly-named-svn-branch-hierarchies, and
git pulling between git-svn users, however, have given us lots of
grief.

For example, I'd be very happy to learn that your new design would
allow two people to independently pull from svn://, do work in their
respective copies of the git repositories, branch and merge all day
long, pull from each other, and then push back to svn without a)
making a mess of the svn repo and causing zillions of conflicts, or b)
linearizing history and losing git's complex DAG.

In the current version of git-svn this is very hard. 'git svn dcommit'
generates entirely new git commit objects corresponding to the ones
that were created in svn... but which nevertheless have your merge
history included, which is awesome.  But if a new person clones the
svn repo from scratch, he will end up with git commits corresponding
to those same ones from svn, but *without* the merge history, and
therefore with different commit ids, and which therefore prevent
push/pulling between other people who have cloned the repo.

If the above explanation doesn't make any sense, let me know and I can
clarify it further.  If you know what I'm talking about and have
either solved it or don't care about that use case, please just ignore
me and I'll go back to hide in my hole :)

Have fun,

Avery