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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Mar 4, 2012 at 6:54 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote:
> David Barr wrote:
>> On Sat, Mar 3, 2012 at 11:27 PM, David Barr <davidbarr@xxxxxxxxxx> wrote:
>
>>> --- a/SoC-2012-Ideas.md
>>> +++ b/SoC-2012-Ideas.md
>>> @@ -182,3 +182,29 @@ this project.
>>>
>>>  Proposed by: Thomas Rast
>>>  Possible mentor(s): Thomas Rast
>>> +
>>> +Remote helper for Subversion
>>> +------------------------------------
>>> +
>>> +Write a remote helper for Subversion. While a lot of the underlying
>>> +infrastructure work was completed last year, the remote helper itself
>>> +is essentially incomplete. Major work includes:
>
> By the way, didn't we have a remote-svn prototype?  I'm happy to merge
> any old hacky thing for staging in contrib/svn-fe, as long as it is
> not documented in a misleading way.
>
> (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)

The introduction should be rephrased to include Dmitry's progression.

>>> +* Understanding revision mapping and building a revision-commit mapper.
>
> Does this mean creating commit notes to record which subversion rev
> corresponds to each commit, and marks or lightweight tags going the
> other way?

Yes. I think once again, Dmitry produced a good prototype for this component.
However, I think it also potentially incorporates git-svn style
slicing of history.
That's a significant chunk of work.

>>> +* Working through transport and fast-import related plumbing, changing
>>> +  whatever is necessary.
>
> I think Dmitry and Sverre took care of most of this.

Ditto.

>>> +* Getting an Git-to-SVN converter merged.
>
> Probably could fill a summer in itself.  In previous starts I think
> there was some complexity creep. :/
>
>  http://thread.gmane.org/gmane.comp.version-control.git/170290
>  http://thread.gmane.org/gmane.comp.version-control.git/170551

This is my preferred focus, and is a sufficient project in its own right.

>>> +* Building the remote helper itself.
>>> +
>>> +Goal: Build a full-featured bi-directional `git-remote-svn` and get it
>>> +      merged into upstream Git.
>
> Sure would be neat. ;-)  Another nice piece to build would be branch
> tracking / follow_parent heuristics.

As noted earlier, the remote helper itself is now half-complete.
I do think the immediate goal should be bi-direction.
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

--
David Barr
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]