[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge 'svnmover' demo tool to trunk

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 12 Nov 2015 10:19:24 +0100

On Tue, Nov 10, 2015 at 4:28 PM, Julian Foad <julianfoad_at_apache.org> 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.

-- 
Johan
Received on 2015-11-12 10:19:48 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.