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

Re: future of our "experimental" features

From: Paul Hammant <paul_at_hammant.org>
Date: Fri, 24 Jan 2020 13:39:58 +0000

I think y'all should promote something to mainstream, even if the
performance isn't what you want it to be (for this feature). Better slow
IMO, than "does the wrong thing". If y'all promote neither it'll just
decay away from trunk and then risk never going live. As it doesn't affect
any existing part of Subversion its case for merging into trunk is stronger.

I cobbled together a "VCS Nirvana" blog entry some days ago -
https://paulhammant.com/2020/01/19/vcs-nirvana.

-ph

On Fri, Jan 24, 2020 at 12:18 PM Julian Foad <julianfoad_at_apache.org> wrote:

> Stefan Sperling wrote:
> > There are a few features in 1.13 still declared "experimental".
> >
> > Experimental subcommands:
> > x-shelf-diff
> > x-shelf-drop
> > x-shelf-list (x-shelves)
> > x-shelf-list-by-paths
> > x-shelf-log
> > x-shelf-save
> > x-shelve
> > x-unshelve
> > x-wc-copy-mods
> >
> > It sounds like Julian won't have time to keep working on them. So unless
> > someone else picks them up, will they stay in experimental status
> forever?
> >
> > Did the concept of "experimental feature" have the desired results?
> > As far as I remember the goal was to gather feedback from users before
> > finalizing on-disk formats and APIs. Did this work out as planned?
> >
> > Is there any reason why we should not simply move these features to an
> > officially supported status on trunk now, and in the future 1.14?
> > Alternatively, should these features be excluded from 1.14 because they
> > aren't finished? Perhaps even be removed from trunk?
> >
> > I had good results with incrementally developing the conflict resolver by
> > gathering feedback from users and fixing issues and adding improvements
> > in future releases. So I don't really see a need to be extra careful by
> > labeling features as "experimental" and I would be in favour of declaring
> > these commands as officially supported, unless anyone can present a
> reason
> > not to do so. (Disclaimer: I have not yet used these commands and have
> not
> > reviewed their design and implementation myself.)
>
> Thanks for bringing this up.
>
> Shelving:
>
> The current incarnation of shelving ("v3") is feature-wise better than
> the previous incarnations but performance-wise unusably slow on medium
> to large WCs, because it uses a crude, complete "svn checkout" to create
> a shelf storage base state before (reasonably efficiently) shelving the
> changes into it.
>
> Frankly, in this state, probably the older implementation (shelving "v1"
> from svn 1.10) is more useful in practice to more users. Based on
> saving patch files created by "svn diff" and "svn patch", the "v1"
> implementation fails to shelve many kinds of WC modifications other than
> plain text changes, but its performance characteristics are in line with
> expectations, proportional to size of changes.
>
> The current implementation does prove and exercise the new APIs I put in
> place to neatly copy changes into and out of a WC, so it has a
> development value.
>
> I am not sure what to do about this. Abandon, revert to "v1", keep as
> is, put both versions in?
>
>
> svn x-wc-copy-mods:
>
> The copy-mods feature is a reasonably good implementation of a
> feature-complete upgrade for "svn diff in dir X | apply patch in dir Y".
> The main reason why I left it "experimental" is because it doesn't fit
> neatly into the existing command-line UI functions and command names,
> and other corresponding.
>
> Even though it's a niche feature, I suggest we could promote it to a
> non-experimental status, on the basis that the svn command-line client
> has a valid secondary role to play in exposing a basic UI onto all the
> available client API functionalities, as well as its role in providing a
> UI tailored to users' most common tasks.
>
>
> svn info --x-viewspec=
>
> This is not ready to be promoted to non-experimental. This command
> itself is not too bad; what is missing is a proper efficient
> implementation of "apply a viewspec". I consider that forces us to keep
> this "report the current viewspec" command as "experimental".
>
> - Julian
>
Received on 2020-01-24 14:40:18 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.