Re: Merge 'svnmover' demo tool to trunk

On Thu, Nov 12, 2015 at 11:44 AM, Julian Foad <julianfoad_at_apache.org> wrote:
> Johan Corveleyn wrote:
>> Julian Foad wrote:
>>> The work on the 'move-tracking-2' branch currently consists of some
>>> library functions (mostly named 'svn_branch_*') which are used only by
>>> the demo tool named 'svnmover'. These do not interfere with normal
>>> Subversion operation at all. I propose to merge this to trunk to lower
>>> the barrier to participation in this work.
>>>
>>> I first need to review a few places where I touched existing code to
>>> insert 'shims'; only a small part of this would remain, I think, as
>>> bidirectional shims are not currently available.
>>>
>>> Any objections?
>>
>> No concrete objections.
>>
>> But it makes me wonder: what is the big plan for svnmover and its
>> concepts, both on the short term (1.10) and the longer term?
>>
>> Do you intend to release it as an experimental demo tool in 1.10, to
>> give it more visibility and to be able to get feedback from users? In
>> that case, will we be able to avoid confusion (people might think it's
>> a core tool, a next generation ui, the real thing, ...)?
>>
>> But the bigger question is the long term question: what's the eventual
>> goal for this? Do you aim for a parallel world, or a complete
>> reimplementation of certain concepts (in that case, perhaps this is
>> 2.0-ish)? Or do you want to integrate certain ideas, elements, ui, ...
>> into the core? And in doing so, add new plumbing for your model, as an
>> "enrichment" of the existing model; or build on the existing plumbing
>> to support certain higher level concepts, ....?
>>
>> If this is to be integrated into trunk, and thus in some form released
>> in 1.10, I'd like to know where we're going with this.
>
> Excellent questions, Johan. Thanks for asking them.
>
> The Big Plan is a thing that we -- you and the others and me -- need
> to work out together. I don't know if that will be seamlessly merging
> new models into the existing Subversion framework, or starting off by
> building a completely new and incompatible system, or some approach in
> between those extremes.
>
> 'svnmover' is a program for helping developers to understand and try
> out some concepts that I think are helpful. It is not intended to be
> useful for end-users, and I hadn't even thought about releasing it. As
> such, maybe it shouldn't appear as a top-level executable but
> somewhere else, perhaps in 'tools' or 'contrib'.
>
> I want to bring this to trunk because I can't do this on my own. I
> think it's the number one most important thing that Subversion needs,
> and so I passionately want to make it work in some way. I have done a
> big batch of solo thinking and scratched hundreds of sketches on scrap
> paper, which was productive and resulted in what I think are some good
> ideas, but there are still some big gaps in how to fit them together
> into a real Subversion.
>
> The phase we're at is the phase of sharing new concepts and interest
> and ideas among ourselves, and I hope to be able to convince you that
> although a big and difficult project, it is worth our while and we can
> do it.

Ack, thanks for explaining.

I agree that better move support is probably the number one priority
for Subversion (whether it's done with a model explicitly tracking
"elements", or through better tree conflict resolution using the
existing model (as stsp advocated during the last Berlin hackathon) --
or both supplementing each other).

Perhaps this is indeed the time to bring your prototype to trunk (in
tools) to give it more visibility, and to make further progress. There
are some good ideas in there, and it's great to see something in
action to see how it behaves.

I'm still very much wondering how this will fit in with the general
direction of Subversion ... but as you say, that's something we need
to work out together. That, for me, is currently the biggest part of
the puzzle.

Thanks for your work on this.

-- 
Johan