Re: GSoC proposal for svn remote helper

[Dmitry Ivankov <divanorama@gmail.com>]

Hi

On Sat, Apr 9, 2011 at 4:31 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> At the moment I am more concerned with what its guts will look like
> than what features it will support.  A feature list is just a way to
> advertise how good the guts are. ;-)
My current view is following:
Use svnrdump stream to track / in say svnroot branch. It'll be linear
(1), commits will include actual diffs, and some revprops translated
to their git counterparts like svn:log,svn:author,svn:date (2). And
it'll be a bridge for svn interaction.
In git-notes tree store sha1 -> svn rev mapping(3), and also for each
svn rev store all it's revprops.
Store and maintain /path branches - there we have some freedom of
choosing git parents.
That's all about fetch. Obviously svnrdump will be used to push
fast-forward linear history back to svnroot, or to a /path branch
which goes the same way in fast-forward case.
And to be somewhat usable we want to be able to rebase-push/dcommit
(if there is a dense stream of svn commits going, we don't want the
user to type git rebase, git push and fail until he gets a lucky
timing).
Merges need more thinking, and may be not that necessary for a start.
Path ignores, or even revision ignores should be possible to implement
in the code, but just an emergency tools for a user (sometimes people
(by mistake) commit something enormous or incompatible with
filesystems names or like, so that user considers it ok to trash this
out of his history), also there could be a need for permanent path
filter (like track /projX, not /bin) - just the same, be ready that
sometime it'll have to be implemented.

[skipped some of svn commit "races" and merge tricks]

>> -- if it was, create a svn branch of our parent, commit there, and
>> then create a merge commit of these two, commit it and get same merge
>> history back
>
> Yikes.  I don't think typical projects would like the resulting
> history.
Will make them mad, but in some cases it should be ok, if we are
pushing a lengthy topic branch they'll sometimes prefer to see it as
one commit.

> Yes, this is an interesting question.  Given a history like this (time
> flowing left to right):
>
>         E --- F --- G
>        /             \
>  A --- B --- C -- D -- H
>
> where A is the latest rev of trunk/, how do we push this history to
> svn?  Where is the name of the side branch recorded in the git
> history?
Could be either autogenerated with some user pattern, like
/branches/user/tmpXX, or specified explicitly in git-notes or
somewhere, or maybe we have already pushed a placeholder branch to svn
and will commit there.
>
> On answer is that it's possible to learn the historical branch name by
> parsing the commit message for "H".  Yuck.
>
> I'd put off pushing merges to start.
It's definitely not in the minimal plan.

> I think the cleanest solution is often to reject a push if it is not
> obvious how to represent it remotely, just as though the remote server
> had a hook that rejected it.
Makes sense, after all plain svn users want to see svn-like history,
because they still use svn.

(1) In theory we could track whole svnroot merges (from svnroot2 on
the same repo for example, or hypothetical merge from another repo)
but that's hardly used by anyone.
(2) The hardest thing is to decide which ones to store in git.
Translating more gives a better look and feel, translating less
reduces the chances to get the same git objects on another clone. And
what should git do if this data changes is not a trivial choice too.
(3) And a funny thing is could happen that there are path1@rev1
path2@rev2 that produce the same sha1. That's perfectly fine because
they are just refs, care should be taken when choosing a path to
commit to though. Also svn will distinguish them, but it's just a
corner case.