Re: [RFC] "Remote helper for Subversion" project
From: Jonathan Nieder <hidden>
Date: 2016-06-15 22:53:12
David Barr wrote:
On Sun, Mar 4, 2012 at 6:54 PM, Jonathan Nieder [off-list ref] wrote:
quoted
(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