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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 20, 2010, 09:19 UTC
Message-ID: <f3271551003200219s5da3d620n602227eed948da70@mail.gmail.com>
In-Reply-To: <32541b131003191430ld0eaa9cw1d2aac08cff15682@mail.gmail.com>

Hi,

Show 6 quoted lines

> So if your goal is to write a possibly better replacement to git-svn,
> that's a potentially great goal with an unfortunately high probability
> of failure (but great upside if you don't fail).  If you won't
> consider it successful unless it gets merged upstream... then you're
> setting yourself up for disappointment, at least if you expect to be
> done withing the GSoC timeframe.

As Sverre pointed out, this is not the goal of the project. The proposal is not to rewrite git-svn. You're probably right to assume that any such endeavor would be unsuccessful in one summer. The proposal is to create an application that will natively support SVN repositories in Git. I'm simply pointing out the limitations of git-svn as a motivation for this project.

As I've mentioned in my proposal, good SVN exporters already exist, and creating an SVN client can be fairly elementary. The whole point of the project is to move away from the "git-svn.perl approach". Ofcourse, that doesn't mean that I won't use some parts of git-svn in native-git-svn. Along with creating the infrastructure for this approach, I do expect to have *working* native SVN support at the end of summer merged into mainline.

I'll make this clearer in the next revision of my proposal.

> You could always do your whole project in python or perl and make it
> *work* the way you want.  If it's really good, you can maybe get that
> accepted into the git core.  Then, if it's really modular enough, you
> ought to be able to rewrite the modules one by one into C as needed.

Writing everything in C can be quite painful. I plan to start off by prototyping the various components in Python anyway. If and when it's necessary, components can be re-implemented in C.

Show 8 quoted lines

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

Oh, that's terribly ugly. Thanks for pointing it out. I haven't thought of a solution yet, but yes- it would be really nice if the new design could handle this elegantly.

Do feel free to tell me what you'd like to see in the next revision of my proposal, and what you'd like to see omitted. A proposal can't run into many pages, so I'll attach anything that's very detailed as notes.

Thanks, Ramkumar