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 13:18:36 CET