Re: [RFC] "Remote helper for Subversion" project

[Jonathan Nieder <jrnieder@gmail.com>]

David Barr wrote:
> On Sun, Mar 4, 2012 at 6:54 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:

>> (More generally, if anyone wants to resend useful svn-fe patches, that
>> will help a lot.)
>
> Found at former SoC2011Projects wiki page:
> (http://git.wiki.kernel.org/articles/s/o/c/SoC2011Projects_b1f9.html#Remote_helper_for_Subversion_and_git-svn)
> [vcs-svn, svn-fe: add a couple of
> options](http://thread.gmane.org/gmane.comp.version-control.git/176578)
> [remote-svn-alpha
> updates](http://thread.gmane.org/gmane.comp.version-control.git/176617)

Do you mean these are patches that should be applied?  New emails
containing a git url or, even better, the actual patch are best, since
it means I can be sure I am looking at the latest or at least the
intended version of the change.

[...]
> However, I think it also potentially incorporates git-svn style
> slicing of history.

Do I understand correctly that you mean paying attention to copy-from
information, like "svn log" does?  (For example, making cloning

	svn::http://svn.example.com/project/branches/feature

when branches/feature was originally copied from trunk involve
grabbing "http://svn.example.com/project/trunk" in early revs?)

[...]
> The remainder is porting git-svn logic to the new helper.
> However, it would be interesting to see what's missing with respect to porting

While git-svn can be useful for inspiration when wondering "how could
I possibly solve such-and-such problem", I'm not sure feature-parity
with git-svn is too important.  After all, people needing git-svn
features can still use git-svn.

I say this since git-svn has lots of features we are missing:
not discarding unhandled properties (important), shared history with
multiple branches, author mapping, fetching and pushing svn:mergeinfo
information, partial clone via a path-ignore regex, choice of
timezone, filename reencoding, manual svn:ignore-to-gitignore
conversion, svn-compatible "log" and "blame" output, custom git<->svn
branchname mappings, and so on.  The ability to track one branch,
including push support, with a linear history would be exciting
already and doesn't require all that.

Cheers,
Jonathan