Re: Pristines-on-demand: OK to merge to trunk?

[Daniel Sahlberg]

Den tors 7 apr. 2022 kl 13:43 skrev Julian Foad :

> TL;DR: are we OK to merge the pristines feature
> ('pristines-on-demand-on-mwf' branch) to trunk soon, like early next week?
>
> As said in "A status review" [1] in the long thread "A two-part vision
> for Subversion and large binary objects.", next steps are reviewing and
> handling the outstanding issues, and proposing merge to trunk. I think
> these can be done in parallel as I don't see any that would block a
> merge to trunk. So here is the proposal to merge to trunk, and then
> complete the remaining work on trunk.
>
> It feels to me like there is general consensus that this feature is
> taking a form that will be acceptable for a first release of it (while
> not perfect), and consensus for proceeding to get it into trunk and
> subsequently including it in the next release. I'm too close to it to
> make an independent assessment. Can anybody else comment?
>
> If no objections, I plan to merge to trunk early next week.
>

I can't really make a judgement on the "ready to merge" question, just
wanted to add a data point that I've built TortoiseSVN with the
pristines-on-demand-on-mwf branch and made a few successful tests on the
command line tools.

The GUI complained that I need to upgrade my working copy after I did `svn
upgrade --compatible-version=1.15`, I hope to look into this during the
weekend.

If everything goes well I'm planning to use this as my daily driver on a
mix of 1.8- and 1.15-version working copies. (Yes, I'm aware of the risks).

Kind regards,
Daniel Sahlberg

Re: Pristines-on-demand: OK to merge to trunk?

[Daniel Shahaf]

Julian Foad wrote on Thu, Apr 07, 2022 at 12:43:03 +0100:
> TL;DR: are we OK to merge the pristines feature
> ('pristines-on-demand-on-mwf' branch) to trunk soon, like early next week?
> 
> As said in "A status review" [1] in the long thread "A two-part vision
> for Subversion and large binary objects.", next steps are reviewing and
> handling the outstanding issues, and proposing merge to trunk. I think
> these can be done in parallel as I don't see any that would block a
> merge to trunk. So here is the proposal to merge to trunk, and then
> complete the remaining work on trunk.
> 
> It feels to me like there is general consensus that this feature is
> taking a form that will be acceptable for a first release of it (while
> not perfect), and consensus for proceeding to get it into trunk and
> subsequently including it in the next release. I'm too close to it to
> make an independent assessment. Can anybody else comment?
> 

Although I've done some work on the branch, and did at points diff to
trunk for a specific thing I was working on at the time, at no point did
I do a complete start-to-finish review, as would be needed before
a merge.  So, please do *not* count me as an implicit +1.

Also, I'd be wary of merging the branch to trunk so long as there are
blockers, unless whoever does the merge is certain they will have
sufficient (round) tuits to fix those blockers in a timely manner.

Cheers,

Daniel

> If no objections, I plan to merge to trunk early next week.
> 
> [1] on dev@, 2022-04-05, 
> https://lists.apache.org/thread/lm98og8jqonffcs250q5y3ft5r5qlmk5
> 

Re: Pristines-on-demand: OK to merge to trunk?

[Julian Foad]

Nathan Hartman wrote:
> The branch worked for me when I last tested it and I saw no glaring
> issues so I have no objections to merging it soon. That said, I would
> encourage, if at all feasible, that we try to do two things first:
> decouple the format 32 and pod525 feature, and decide what the
> user-facing feature and its CLI switches should be called so that our
> internal "plumbing" names won't stick forever as the user-visible
> terms... If we can only do one of these, it should probably be the naming.

For "decouple the format 32 and pod525 feature", see email thread
"Pristines-on-demand=enabled == format 32?" 
.

Naming
==

What naming do we want? I'm perhaps too close to the code. Some
potentially good ideas have been floated in the past, none very
obviously best but perhaps we can pick a good one from them. Some
suggestions were along the lines of:

  * "bare WC"
  * "blob-optimised WC"
  * "[no] local cache" (of text-bases)
  * "[no] trade space for speed"

(just off the top of my head).

The feature name hardly appears in the UI, so far. The places I can
think of are:

  * a progress notification: "Fetching text bases...",
  * perhaps a dedicated option name for checkout/upgrade, as being
discussed in the "decouple" thread mentioned above;
  * release notes;
  * user guide (where currently a place-holder 'POD525' is used for the
feature name).

- Julian

Re: Pristines-on-demand: OK to merge to trunk?

[Nathan Hartman]

On Thu, Apr 7, 2022 at 7:43 AM Julian Foad  wrote:

> TL;DR: are we OK to merge the pristines feature
> ('pristines-on-demand-on-mwf' branch) to trunk soon, like early next week?
>
> As said in "A status review" [1] in the long thread "A two-part vision
> for Subversion and large binary objects.", next steps are reviewing and
> handling the outstanding issues, and proposing merge to trunk. I think
> these can be done in parallel as I don't see any that would block a
> merge to trunk. So here is the proposal to merge to trunk, and then
> complete the remaining work on trunk.
>
> It feels to me like there is general consensus that this feature is
> taking a form that will be acceptable for a first release of it (while
> not perfect), and consensus for proceeding to get it into trunk and
> subsequently including it in the next release. I'm too close to it to
> make an independent assessment. Can anybody else comment?
>
> If no objections, I plan to merge to trunk early next week.
>
> [1] on dev@, 2022-04-05,
> https://lists.apache.org/thread/lm98og8jqonffcs250q5y3ft5r5qlmk5
>
>
The branch worked for me when I last tested it and I saw no glaring issues
so I have no objections to merging it soon. That said, I would encourage,
if at all feasible, that we try to do two things first: decouple the format
32 and pod525 feature, and decide what the user-facing feature and its CLI
switches should be called so that our internal "plumbing" names won't stick
forever as the user-visible terms... If we can only do one of these, it
should probably be the naming.

Cheers,
Nathan

Pristines-on-demand: OK to merge to trunk?

[Julian Foad]

TL;DR: are we OK to merge the pristines feature
('pristines-on-demand-on-mwf' branch) to trunk soon, like early next week?

As said in "A status review" [1] in the long thread "A two-part vision
for Subversion and large binary objects.", next steps are reviewing and
handling the outstanding issues, and proposing merge to trunk. I think
these can be done in parallel as I don't see any that would block a
merge to trunk. So here is the proposal to merge to trunk, and then
complete the remaining work on trunk.

It feels to me like there is general consensus that this feature is
taking a form that will be acceptable for a first release of it (while
not perfect), and consensus for proceeding to get it into trunk and
subsequently including it in the next release. I'm too close to it to
make an independent assessment. Can anybody else comment?

If no objections, I plan to merge to trunk early next week.

[1] on dev@, 2022-04-05, 
https://lists.apache.org/thread/lm98og8jqonffcs250q5y3ft5r5qlmk5