Re: [RFC] "Remote helper for Subversion" project
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Mar 4, 2012, 16:23 UTC
- Message-ID
- <20120304162322.GB17923@burratino>
- In-Reply-To
- <CAFfmPPPs0FRbT-i+ZwBLNSca330Eo7thjNxDt3hJf0yUATthtQ@mail.gmail.com>
David Barr wrote:
> On Sun, Mar 4, 2012 at 6:54 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 9 quoted lines
>> (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