On Fri, Jan 24, 2020 at 12:18:32PM +0000, Julian Foad wrote:
> 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.
How much work do you think is required to fix that?
Was there a plan already or is design work required?
> 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?
Sounds like we should reinstate shelving-v1 on trunk and put the
shelving-v2 code on a branch, for now?
> 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.
Great. Could this become an optional mode for 'svn copy'?
> 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".
In that case I would prefer to move it to a branch instead of having
it on trunk.
Received on 2020-01-24 15:35:26 CET