[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: Julian Foad <julianfoad_at_apache.org>
Date: Fri, 31 Jan 2020 15:08:35 +0000

Stefan Sperling wrote:
> Julian Foad wrote:
> > Shelving: [...] uses a crude, complete "svn checkout" to create a shelf
>
> How much work do you think is required to fix that?
> Was there a plan already or is design work required?

It needs design and quite some work, so off the radar until someone
invests further in it (whether financially or as a volunteer).

> Sounds like we should reinstate shelving-v1 on trunk and put the
> shelving-v2 [edit: it's v3] code on a branch, for now?

Maybe yes.

> > svn x-wc-copy-mods:
>
> Great. Could this become an optional mode for 'svn copy'?

No, it's unlike "copy" and more like "diff-and-patch", but with an API
that supports all committable changes, not only those that the "diff"
and "patch" serialization format currently supports.

> > 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.

In terms of whether it is visible by default to an users, I agree. In
terms of where the source code lives, I don't mind -- I would be equally
happy if it were on trunk and disabled by a compile time or run time
feature flag.

In particular, I think it is important to keep the visible behaviour
"stable" which implies I think we should stop exposing these
experimental features by default; and at the same time we don't want to
make anything more difficult to develop than necessary, so maybe we
should not be too eager to push things onto branches.

- Julian
Received on 2020-01-31 16:08:36 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.