Clarify whether svnadmin commands are safe to run on a live repo

Yesterday I was pleased to notice that we had gained an "svnadmin build-repcache" command in 1.14, thanks to Denis Kovalchuk of VisualSVN. https://subversion.apache.org/docs/release-notes/1.14#svnadmin-build-repcache https://svn.apache.org/r1875921 To an inexperienced svn admin, this feels l

Re: svn extension to access OAuth2-protected repositories

Evan, I for one think it would be great for Subversion to have more modern auth options. Thank you for presenting your proof of concept of such an extension. As to your direct question, while it's possible someone might pick up the idea and run with it, in all honesty it is most likely you w

Re: Removing the old move-tracking experiment

Nathan Hartman wrote: I am okay with this (conceptually [...]). More specifically, I am okay with removing it from trunk, but may I suggest moving it to a branch, e.g., 'svnmover'? [...] Thank you for your thoughts on this, Nathan. I went ahead, removing it from trunk (r1915902) and making

Removing the old move-tracking experiment

=== Index: tools/dev/svnmover/ra.c (deleted) === Index: tools/dev/svnmover/scanlog.c (deleted) ======= Index: tools/dev/svnmover/svnmover.c (deleted)

Re: Getting to first release of pristines-on-demand feature (#525).

I'm glad to see you all picking up this project again. While working on this at the beginning of the year I turned on the pristines-on-demand mode in some of my own WCs such as my 'Documents' tree which includes lots of scanned paper docs. It works nicely for cases like this, and feels right, the p

SVN-4832 Authz perf regression 1.9 -> 1.10

I did some profiling for SVN-4832 "Authz perf regression 1.9 -> 1.10" . I updated the issue with my findings, including a sample of the debug timings output from my debug code. TL;DR: if an authz file specifies a large number of ACLs and a large number of

Re: Subversion 1.10.0 end-of-life

Just to add my support: I am glad to see the community adapting the release policy to suit the current circumstances.

Re: Initial patch for storing the pristines-on-demand setting in the working copy (Issue 4889)

Evgeny Kotkov wrote: > first-cut implementation that persists the pristines-on-demand setting This is great! Thank you Evgeny. > The patch currently allows doing an `svn checkout --store-pristines=no`, > which is going to create a working copy that doesn't store the pristine > copies of the files

Re: Pristines-on-demand: printing progress notifications

Daniel Shahaf wrote: > I'm a bit hesitant about disabling notifications _entirely_ in cat-cmd.c > and diff-cmd.c. Disabling all notifications (as opposed to only > hydration-related notifications which we focus on right now) seems like > it could easily have unintended consequences. Do we do that

Re: Question on release announcement mail

Mark Phippard wrote: >Looking at past release announcements, they include a section on who >signed the release that looks like this: [...] >I am kind of at a loss for how to produce this information. [...] There's a 'release.py' subcommand that writes this email for you, if I recall correctly. - J

Re: Pristines-on-demand: fix disabled tests (#4891)

Johan Corveleyn wrote: >Should be fixed now, with r1899654. Great! Thanks. >I suppose not passing the option uses wc-format-version=1.15 No... >automatically? Or what is the default? Is format 1.8 the same as 1.14 >and anything in between? Default would be the format '31' which is 1.8 through

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

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 >

Re: Pristines-on-demand=enabled == format 32?

Johan Corveleyn wrote: > Ah, yes, I think that makes #4889 a blocker. Well, I'm having a hard time deciding what exactly we need and why. I previously said "it's pretty clear it needs to be uncoupled" but actually just now I've dived into it for a couple of hours, coding and thinking, and it's no

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

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,

Re: A two-part vision for Subversion and large binary objects.

Julian Foad wrote: > Pristines (#525): > - #4888 authz denied during textbase sync >(an edge case issue, not sure if it's a blocker) > - #4889 per-WC config >(wanted) > - #4891 fix disabled tests >(a few different edge cases; much of the analysis is posted

Re: Pristines-on-demand: fix disabled tests (#4891)

Johan, that's a great start, thanks. Now can you run the test suite with --wc-format-version=1.15? On Unixy systems that is done by, for example: $ make svnserveautocheck WC_FORMAT_VERSION=1.15 ... Jun Omae wrote: >> FAIL: diff_tests.py 48: svn diff --diff-cmd provides the correct arguments >

Re: Pristines-on-demand: fix disabled tests (#4891)

Today I have done a quick review/fix/postpone cycle on the 'upgrade', 'update', and 'trans' tests. Details in https://subversion.apache.org/issue/4891 . - Julian

Re: Pristines-on-demand: fix disabled tests (#4891)

Johan Corveleyn wrote: >> A few of these are Windows-specific. I can't very well investigate those >> myself. Who could volunteer to look at those? They are: >> >> externals_tests.py ... ... ...: >> update_modify_file_external(), >> remap_file_external_with_prop_del(), >> fil

Re: Pristines-on-demand=enabled == format 32?

Johan Corveleyn wrote: > I think this was asked several times before, but I can't find the > thread: is the pristines-on-demand behavior still unconditionally tied > to format 32? Or is it that format 32 makes it _possible_ to enable > pristines-on-demand? Currently it's tied to f32, but it's pret

Pristines-on-demand: fix disabled tests (#4891)

One of the main things blocking pristines-on-demand now is a few edge case test failures. It would be great if we could get some further eyes on these. On the branch, these failures have been converted to XFAIL by adding '@Wimp' decorators. Some of them seem to fail even when run against the old

Re: Pristines-on-demand: authz denied during textbase sync (#4888)

Evgeny Kotkov wrote: >> - revert the patch I applied, as it's papering over the problem in an >> incomplete way and so possibly causes more confusion than it fixes. >> >> - leave this issue open and come back to it later; it's an edge case not >> part of common work flows. > > +1. Thanks! Revert

Re: Pristines-on-demand: authz denied during textbase sync (#4888)

> Filed as issue #4888, https://subversion.apache.org/issue/4888 I have just been looking back over this issue. Clearly there is more to it than a quick fix. Summary, based on reviewing the email thread: - FAIL: authz_tests.py 31 remove_access_after_commit - Patched in

Re: A two-part vision for Subversion and large binary objects.

A status review from my P.O.V. Pristines (#525): * issues filed (potential blockers): - #4888 authz denied during textbase sync (an edge case issue, not sure if it's a blocker) - #4889 per-WC config (wanted) - #4891 fix disabled tests (a few different edge cases; much of the a

Re: Should tarballs contain __pycache__ dirs?

Yasuhito FUTATSUKI wrote: >> ./build/__pycache__ >> ./build/generator/__pycache__ >> ./build/generator/swig/__pycache__ >> >> Are they supposed to be present in the tarball? > > I don't think they are supposed. Agreed. > Those directries should be cleaned in fast-clean and clean-swig-py > targe

Re: Website prep work and questions (mainly about the 1.15 release notes)

Mark Phippard wrote: > Julian Foad wrote: >> Me too. It appears I need to update my configured keyserver. Then >> maybe fetch keys and then maybe the checking will work. That's based >> on, so far, finding that checking existing keys fails due to >> unreacha

Re: Subversion 1.14.2 up for testing/signing

Passed and signed. Test environment: Unix (Ubuntu 21.10) Tested: (serf, svn, local) x (fsfs) bindings: javahl, swig-pl, swig-rb Not tested: bdb, swig-py, ctypes-python Dependency versions (Ubuntu distribution-supplied packages): SQLite (from source at: /usr) libapr1 1.7.0-6ubuntu1 l

Re: Subversion 1.10.8 up for testing.signing

Passed and signed. Test environment: Unix (Ubuntu 21.10) Tested: (serf, svn, local) x (fsfs) bindings: javahl, swig-pl, swig-rb Not tested: bdb, swig-py, ctypes-python Dependency versions (Ubuntu distribution-supplied packages): SQLite (from source at: /usr) libapr1 1.7.0-6ubuntu1 l

Re: Website prep work and questions (mainly about the 1.15 release notes)

> I'm in the middle of the > process of testing, however I have some trouble with the gpg keys [...] Me too. It appears I need to update my configured keyserver. Then maybe fetch keys and then maybe the checking will work. That's based on, so far, finding that checking existing keys fails due to

Re: Pristines-on-demand: printing progress notifications

Karl Fogel wrote: > I think printing these messages to stderr makes the most sense. > There are plenty of programs out there that parse the stdout of > 'svn'; we don't want to interfere with them. > > As you point out, it's especially important for 'svn diff' and > 'svn cat' that stdout remain

Re: Pristines-on-demand: printing progress notifications

Finished and committed: https://svn.apache.org/r1899173 . This looks and feels much better to me now. Example: $ svn revert -R subversion/ Fetching text bases ..done Reverted 'subversion/svn/cat-cmd.c' Reverted 'subversion/svn/diff-cmd.c' Reverted [...] - Julian

Re: Pristines-on-demand: printing progress notifications

Updated and cleaned-up patch 'hydrating-notifications-2.patch' attached, for interest. Still TODO: update test expectations. hydrating-notifications-2.patch Description: Binary data

Re: Pristines-on-demand: printing progress notifications

Daniel Sahlberg wrote: > How does svn cat handle any other informative or warning messages? I don't think 'svn cat' prints any other informative or warning messages. It occurs to me now that anything on stderr is generally assumed to indicate an error, in tests in the test suite. We need to updat

Re: Pristines-on-demand: printing progress notifications

For 'svn diff' especially, if we don't print the notifications, then we miss out on informing the user during one of the times when it could be particularly valuable to them. (They are waiting for diff output, which previously in svn used to come quickly.) It would be ugly to print these notificat

Re: Pristines-on-demand: printing progress notifications

I made a mistake in: > 'svn cat' already suppresses these notifications. CORRECTION: 'svn cat' currently prints these notifications. 'svn diff' currently prints these notifications. --> TODO: stop printing them here. It seems the only change needed here is to make both 'svn diff' AND 'svn cat'

Re: Pristines-on-demand: printing progress notifications

Daniel Sahlberg wrote: >> I'll put it on my todo list, but I can't promise when I find time to >> to that. I only meant to ask you to clarify what you meant: whether you are reporting for TSVN 1.14 or a TSVN 1.15-dev build (based on the pristines-on-demand branch or otherwise; I don't know if anyo

Re: Pristines-on-demand: printing progress notifications

Marl Phippard wrote: > Yes, and I agree --quiet should suppress. [...TSVN] hooked into our > notifications to be providing an update on bytes transferred. [...] I > just assumed they would work ... maybe they still do? Daniel Sahlberg wrote: >> Yes, I like this very much. The more feedback [...] t

Re: Pristines-on-demand: printing progress notifications

The notifications are printed for any command. Let's please pretend I didn't use 'update' as an example. I don't want us to mix up this discussion with the discussion about how 'update' shouldn't hydrate. Let's pretend I used 'diff' or 'revert' as the example, like this: [[[ $ svn revert -R 1991/*

Pristines-on-demand: printing progress notifications

I thought it would be useful to let users know why Subversion is pausing for a long time where previously it would not have done. I think if I were that user, I would want to know. So I tried the attached patch, printing notifications when it is fetching text-bases. The result looks like this. [[

Re: multi-wc-format: upgrading externals

Daniel Shahaf wrote: > [...] Isn't this orthogonal to the > multi-wc-format work? To date it has always been possible to upgrade an > external without upgrading its parent [...] The > fact that the client doing the upgrade has multi-wc-format support > doesn't affect this logic. > > This would a

Re: multi-wc-format: svn_wc__format_from_version()

Daniel Shahaf wrote: > It doesn't seem to be an old function; the docstring says (in a part I > snipped) it's new in 1.15. However, I don't think that changes the answer. > Done in r1899004. Oh, just older than my involvement then! Thanks. - Julian

Re: multi-wc-format: svn_wc__format_from_version()

That's an old function. "Characteristic" previously meant the only format supported by a given client version. We should change the word now. What should the function return now? The newest, I think: its callers are upgrade and checkout; essentially it is used to implement the --bikeshed=1.15 op

Re: Issue #525/#4892: on only fetching the pristines we really need

Johan Corveleyn wrote: >It's not specific to 'svn update' per se, but it's logical that it >leads to this discussion, because it is a (commonly used) case where >the pristine is not actually needed for the operation (if there is no >actual incoming update to the concerned file). 'svn diff' and 'svn

Re: multi-wc-format review

Daniel Shahaf wrote: > + The upgraded working copy will be compatible with Subversion 1.8 and > + newer (this default may change ... Sure, +1, a bit clearer. Also see Nathan's option-naming proposal at the end of this message. >> Which WC format did our hypothetical user want? (Rhetorical.) The

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: >Also, unrelated: have we verified that all the temporary files we create >are created in a crash-safe way? I.e., that if libsvn_wc is SIGKILL'd >partway through hydrating something, the something will be cleaned up by >libsvn_wc at some point in the future? I haven't reviewe

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: >> The request is to break the original design's invariant for this case. > > By only hydrating files that have been updated repository-side. How > will small, modified files that _haven't_ been remotely modified get > hydrated, then? The logic is the same for small and large

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: >Julian Foad wrote: >> It might be *absolutely fine* for the real life users [...] > >So what are you saying? That we should stop doing design discussions >and go talk to users? [...] Sorry if that came across far too harsh. Looking back I see I phras

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: > [...]I suspect I'm still missing something. I suggest you re-read the issue 4892 use case: https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-issue4892/notes/i525/i525-use-case-4892-minimal-update.txt The request is to break the original design's inva

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: > [...], ourselves. Is HEAD of the branch good enough that devs >with use-cases can start to try it in their real use-case wc's? It >won't be possible to downgrade f32 to f31, but [...] I think so. Anyone trying it should take a quick look through the known bugs filed as de

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: >> Stick with the idea, for now, that we do need to handle that "restore" >> part of update. > >Can we deprecate it? People already argued for keeping it. No need to spend more time discussing that now, as I pointed out the effort required to make it work this new way (fetch

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: >This implies the wc won't be uniform revision. This might break user >expectations; might [...], I'm not sure how your clarification helps us progress. The point is: It might be *absolutely fine* for the real life users in their real life situations, and that's what we nee

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Shahaf wrote: >Julian Foad wrote: >> exploration was enough to show that an initial release based on the >> original approach has possibilities of being improved, incrementally, in >> that way, as and when resources permit. >> >> In other words I am not r

Re: Issue #525/#4892: on only fetching the pristines we really need

Just an addendum, perhaps a more positive portrayal of the brief exploration of the alternative design approach: my assessment is that exploration was enough to show that an initial release based on the original approach has possibilities of being improved, incrementally, in that way, as and when r

Re: Issue #525/#4892: on only fetching the pristines we really need

The patch I sent is now committed in r1898948 as a new branch, 'pristines-on-demand-on-issue4892', for easier dev/test access.

Re: Issue #525/#4892: on only fetching the pristines we really need

Johan Corveleyn wrote: >Well, as I said, I don't have huge binaries myself [...]. That's just me >speculating of course [...] Hi, Johan. I really appreciate you taking the time to write all your thoughts. That kind of speculation has its place and was certainly useful earlier, but we're now at a

Re: Issue #525/#4892: on only fetching the pristines we really need

Daniel Sahlberg wrote: >[...] I will try to build a release for myself and use it for dev work. Thank you Daniel. I'm wondering if I (or we) need to do more to facilitate evaluation. I'm thinking of things like adding some feedback to tell the user what it's doing ("fetching missing pristines no

Re: Issue #525/#4892: on only fetching the pristines we really need

Johan Corveleyn wrote: >Speaking from the peanut gallery, [...] >If I would be a user with several huge binaries in the repo / WC, I >imagine I would not be happy with this proposal. The reason is that I >have always, forever, only done "svn update the-whole-wc". Updating >individual subdirs is mic

Re: Issue #525/#4892: on only fetching the pristines we really need

Mark Phippard wrote: > [...] I just wanted to bring some user perspective [...] Thanks, Mark. Understood. I also want to clarify that this is my pragmatic side speaking. For anyone who doesn't remember me saying this before, I'll repeat that my purist side would love to see us do the alternative

Re: Issue #525/#4892: on only fetching the pristines we really need

Dear dev community, and especially Karl and Mark: A plea to test the current design/implementation. I wonder if we are missing some perspective. We are worried that the current design won't be acceptable because it has poor behaviour in a particular use case. The use case involved running "svn

Re: Issue #525/#4892: on only fetching the pristines we really need

"Restore" isn't involved in our use cases. The only reason I mentioned the "restore" functionality in the first place is because my proof-of-concept patch deliberately leaves that broken because it's non-core functionality, that also will need modifying to make it work in the new way if we proce

Re: Issue #525/#4892: on only fetching the pristines we really need

Mark Phippard wrote: > Is there a way to describe it in a way that a really experienced SVN > "user" not "developer" would understand? Set aside the pristinelsss WC > feature. What is the scenario in previous versions of SVN where this > behavior is kicking in? Hi, Mark. I have been mainly aiming

Re: Issue #525/#4892: on only fetching the pristines we really need

On Mar 11 2022, at 5:07 pm, Mark Phippard wrote: > On Fri, Mar 11, 2022 at 10:24 AM Evgeny Kotkov > wrote: >> >> Julian Foad writes: >> >> > Conclusions: >> > >> > >> > It is certainly possible that we could modi

Re: Issue #525/#4892: on only fetching the pristines we really need

Thank you, Evgeny. That is exactly the kind of discussion we need, and you were able to provide far more detailed insights than I was. That should help us decide how to proceed. As for your thoughts about the current approach for MVP, I tend to agree that your approach is likely to be useful for a

Re: Issue #525/#4892: on only fetching the pristines we really need

With a dive into the main "update" code, I was able to make "update" fetch pristines at the point of use, and so minimally the ones it really needs... I think. So far I have only got it running with "restore" functionality disabled, and run the test suite. I get the (ten) expected fails from the l

Re: Issue #525/#4892: on only fetching the pristines we really need

A quick dive in the "restore" code path led me to: - commit a small refactoring (r1898847 on trunk) to deduplicate the code, which should be useful if we need to do anything like adding callbacks to it; - observe that if we disable "restore", 10 tests fail (4 update tests and 6 others). It ma

Re: A two-part vision for Subversion and large binary objects.

Here is an approach that does *not* satisfy both sides of this argument: [[[ svn propset "svn:no-pristines" "*" doc/ cat >> ~/.subversion/config <<-EOF [auto-props] src/**/*.exe = "svn:no-pristines = *" EOF ]]] and we make standard Subversion control its pristine storage based on looking

Re: Issue #525/#4892: on only fetching the pristines we really need

eeper swim in the source code and see what more I can learn or hack together. - Julian [1] https://lists.apache.org/thread/t7y09576tz5xcqhwzqys3t0vfbdpg861 on dev@ from Julian Foad at 2022-03-04T20:52:38Z.

Re: http URLs should be updated to https

Julian Foad wrote: > +1. Can you send a patch? By the way, the reason I ask if you would be willing, rather than "just quickly doing it" myself, is even a small "obvious" fix like this tends to require more than it initially looks like: checking if it's already do

Re: http URLs should be updated to https

+1. Can you send a patch? - Julian

Re: A two-part vision for Subversion and large binary objects.

Daniel Sahlberg wrote: > I'm taking an opposite position with regards on where this should be > administred. [...] I would prefer a multi-level approach where the > repository (through svn:foo properties) could suggest pristine-less WC I understand completely your case, but the solution you need i

Issue #525/#4892: on only fetching the pristines we really need

This is an investigation into changing the "pristines-on-demand" approach to follow a principle that each operation would only fetch the pristines it really needs. I have begun a "user guide" ( notes/i525/i525-user-guide.md ), with the aim of explaining the principle of operation of the current ap

Re: [jira] [Commented] (SVN-4884) multi-wc-format: user visibility of WC version (info --show-item)

Daniel Shahaf wrote: > Daniel Shahaf commented on SVN-4884: > > Done in r1898739. (Added the WC format and version to `svn info`'s other output modes.) Great! Thanks, Daniel. By the way, I see you cherry-picked a commit from trunk as the commit before this fi

Re: multi-wc-format review

Nathan Hartman wrote: > Suggestion: The user provides the earliest SVN version with which they > want compatibility, and SVN picks the latest WC format version that is > compatible with it. [...] And Daniel Sahlberg wrote: >> Regarding how to handle --wc-format-version=1.9, I'm leaning towards >>

Re: Issue 525 pristines-on-demand: user guide

Karl Fogel wrote: > Might it be better to put that file on the branch, [...] Yes, sure; I'm not really sure why I didn't. There, r1898819, in 'notes/i525/i525-user-guide.md'. - Julian

Re: multi-wc-format review

tool, without being construed as a promise about versions newer than this version. If anyone thinks anything here could seriously mislead, point it out and let's change it. Daniel Shahaf wrote: > Julian Foad wrote on Thu, Mar 03, 2022 at 10:53:13 +: >> [...] it seems clear to me

Re: Issue 525 pristines-on-demand: user guide

Daniel Sahlberg wrote: > [...] an "iff". I guess this might be the "if and only if" meaning [...] Yes it is. OK, can change. > [...] mismatched quotes. Thanks. Both fixed now in my local copy. More substantive reviews are welcome too :-) - Julian

Issue 525 pristines-on-demand: user guide

I have started a detailed user guide for the current design. Attached to issue: Markdown rendered: It is initially intended to help ourselves understand exactly what the current design is and does, especia

Re: svn commit: r1898525 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/upgrade.c libsvn_wc/wc.h svn/help-cmd.c svn/info-cmd.c svn/svn.c

> Recommend to remove RESULT_POOL too, since it is unused and the return > type is a pointer-to-const. You're welcome to if you feel stronger than I do but it's off the bottom of my priority list :-) - Julian

Re: A two-part vision for Subversion and large binary objects.

> Mark Phippard wrote: >> [...] For an update, I think it is unexpected and undesirable. [...] I had a talk with Karl about this, and now I understand the concern much better. (Karl, please correct anything I misrepresent.) He shares the view that it would be unacceptable for 'svn update' to fet

Re: multi-wc-format review

I can think of a number of further API clean-ups possible, related to multi-WC-format support. Commentary: At first we were trying to keep knowledge of WC format numbers internal to libsvn_wc. However it seems clear to me now that we need to expose them. The rest of the system does need to know

Re: svn commit: r1898524 - in /subversion/trunk/subversion: svn/help-cmd.c tests/cmdline/getopt_tests_data/svn--version--verbose_stdout tests/cmdline/getopt_tests_data/svn--version_stdout

Julian Foad wrote: > Daniel Sahlberg wrote: >> Should the following lines also be removed [...] > Oh yes. Thank you. Please do if you have a moment, otherwise I'll get > to it some time this week. I got to it now. r1898535. I note that we might want to replace that with a ma

Re: svn commit: r1898524 - in /subversion/trunk/subversion: svn/help-cmd.c tests/cmdline/getopt_tests_data/svn--version--verbose_stdout tests/cmdline/getopt_tests_data/svn--version_stdout

Daniel Sahlberg wrote: >Should the following lines also be removed [...] Oh yes. Thank you. Please do if you have a moment, otherwise I'll get to it some time this week. - Julian

Re: A two-part vision for Subversion and large binary objects.

Mark Phippard wrote: > That comment specifically talks about diff. [...] For an update, I > think it is unexpected and undesirable. [...] You're right, the comment I pointed to doesn't do anything to justify why 'update' should fetch it. And I agree it would be better if it didn't. Maybe we will b

Re: multi-wc-format review

On Feb 25 2022, Daniel Shahaf wrote: >> [...] we are now deliberately choosing compatibility as the default, > > OK. However, in this case we should document this explicitly, since the > book explicitly documents that «svn upgrade» would upgrade to the "most > recent metadata format supported by

Re: multi-wc-format: upgrading externals

Daniel Shahaf wrote: > multi-wc-format/BRANCH-README mentioned this: > >> [*] New externals working copies must inherit the format from their >>parent working copy, because [...] > > Upgrading a parent working copy upgrades external wc's too. However, > upgrading an external succeeds. Jud

Re: svn commit: r1898378 - in /subversion/trunk/subversion: include/ libsvn_client/ libsvn_wc/ svn/ tests/cmdline/getopt_tests_data/

> Output will be, I suggest, like this: > > * WC format 31, compatible with Subversion v1.8 and newer > * WC format 32, compatible with Subversion v1.15 and newer r1898524.

Re: Creating future-version wc's

Julian Foad wrote: > Daniel Shahaf wrote: >> I expected this to error out hard, since we can't create 1.16-format > Agreed, that seems better. Will do. r1898523. - Julian

Re: Creating future-version wc's

Daniel Shahaf wrote: > [...] % svn co file://$PWD/r --compatible-version=1.16 > [...] svn: warning: W27: Creating working copy version 1.15 instead > [...] > I expected this to error out hard, since we can't create 1.16-format > wc's. (If pristines-on-demand is merged, 1.15 will use f32 but 1

Re: svn commit: r1898389 - in /subversion/trunk/subversion: include/svn_client.h libsvn_client/upgrade.c svn/info-cmd.c svn/svn.c

Daniel Shahaf wrote: >> + case SVN_WC__WC_NG_VERSION: return &version_1_7; > > SVN_WC__WC_NG_VERSION is declared in wc.h, which this file isn't allowed > to use. Ack. Similar cases mentioned elsewhere; I'll fix the private include later as part of API public/private changes. > Why does this

Re: A two-part vision for Subversion and large binary objects.

Summary of status of #525 = Currently on the 'pristines-on-demand-on-mwf' branch. Dev tasks in progress or outstanding: -- * Multi-WC-format dependency (https://subversion.apache.org/issue/4883): - is merged to trunk and reviewed; - some outstanding item

Re: A two-part vision for Subversion and large binary objects.

On Feb 18 2022, Mark Phippard wrote: >> [It fetches and stores pristines of modified files;] it doesn't mean >> "store no pristines" in that WC. > > I am curious what Karl thinks given that he is living this scenario > today and wants the feature. I would think that having update create > pristine

Re: svn commit: r1898378 - in /subversion/trunk/subversion: include/ libsvn_client/ libsvn_wc/ svn/ tests/cmdline/getopt_tests_data/

Thanks for the reviews. Daniel Shahaf wrote: > Missing @since. [...] r1898461. >> +#include "../libsvn_wc/wc.h" > > I don't think libsvn_client is allowed to use this header. I'll fix that later. >> +* compatible with Subversion v1.8 to v1.15 (WC format 31) >> +* compatible with Subversion v

Re: [PATCH] Sketch of per-user/per-wc config for pristines-mode (#4889)

Filed as #4889, https://subversion.apache.org/issue/4889, "Pristines-on-demand: per-WC config"

Re: Pristines-on-demand: authz denied during textbase sync (#4888)

Filed as issue #4888, https://subversion.apache.org/issue/4888 I will come back to it soonish.

Issue #4883: Multi-WC-format

This feature is now filed as https://subversion.apache.org/issue/4883 "multi-wc-format" Re. the four enhancement suggestions I listed earlier in this thread: > - The "svn upgrade" command may grow an option to only show the > current and target working copy versions. Added as a comment to #48

Re: multi-wc-format review

Daniel, Thank you for reviewing multi-wc-format. I think it would be good for us to be able to refer to the issue ​tracker. I'll file a 'multi-wc-format' issue and we can add sub-issues ​for changes we need or want. https://subversion.apache.org/issue/4883 "multi-wc-format" Daniel Shahaf wrote

Re: Pristines-on-demand: authz denied during textbase sync

Thanks, Daniel. I'll take a look at this some time in the next few days unless someone beats me to it. Daniel Shahaf wrote: > [...] What race condition is that? The change to authz happened before the >sync, not between the sync and the main operation. Yes, it's not directly related to this; it

Re: A two-part vision for Subversion and large binary objects.

Karl Fogel wrote: > Is the above happening in MVP? Yes. I was describing what Evgeny created last year in the 'pristines-on-demand' branch. > I ask because my understanding of > MVP was that it's not doing this opportunistic fetching/discarding > of bases, but rather that it's a simple per-W

Re: Pristines-on-demand: authz denied during textbase sync

I committed the proposed fix in r1898184: [[[ On the 'pristines-on-demand-on-mwf' branch: fix authz_tests.py 31. This test runs an 'update' after read access permission has been removed from a repository path. The text base sync code errored out when it tried to download this text base. We fix it

Re: Multi-WC-format branch: preparing for merge to trunk

Merged to trunk now. Testers, enhancers welcome. More below. Please try it out if you haven't. The basics: wc format 31: - compatible with svn 1.8 to 1.14 and now 1.15-dev wc format 32: - compatible with svn 1.15-dev only, - as yet introduces no schema changes (we expect those to come when

Re: A two-part vision for Subversion and large binary objects.

Mark Phippard wrote: >> Update starts by hydrating. That means it WILL download any missing >> pristines of modified files, regardless whether any newer revision >> will be found. > > Does the possibility exist to optimize this at all? [...] To understand, we need to recap that this design is bas

  1   2   3   4   5   6   7   8   9   10   >