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

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

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

> 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