Re: Getting to first release of pristines-on-demand feature (#525).
On Wed, Dec 7, 2022 at 12:11 PM Evgeny Kotkov via dev <
dev@subversion.apache.org> wrote:
>
> I think that the `pristines-on-demand-on-mwf` branch is now ready for a
> merge to trunk. I could do that, assuming there are no objections.
I'd like to echo what others have already said by saying a great big THANK
YOU, to all who have worked on this cool new feature so far!
I used an earlier incarnation of this branch some months ago in real usage
scenarios with good results and looking at the recent commit emails as
they've happened everything looks sensible to me.
I will try to run the full test suite in the next couple of days and
assuming the tests pass for me I'll use it as my daily driver to test the
real usage. Obviously I'll post here if I find anything...
Meanwhile I'd like to say that on further thought and after reading Johan's
and Karl's feedback regarding the feature switch naming, I've come around
to the point of view that --store-pristine={yes|no} is a perfectly fine UI.
Given that this is now the command line switch name, and since users are
given direct control over the pristinefulness of a WC, and we've been
calling this feature Pristines On Demand since its inception, I think we
should finally bless this as the official name of the feature.
In the next couple of days I plan to update the staged 1.15 release notes,
which until now tentatively called it Bare Working Copies, to call it
Pristines On Demand and to complete the description there.
Regarding the SHA hash question:
While here, I would like to raise a topic of incorporating a switch from
> SHA1 to a different checksum type (without known collisions) for the new
> working copy format. This topic is relevant to the pristines-on-demand
> branch, because the new "is the file modified?" check relies on the
> checksum
> comparison, instead of comparing the contents of working and pristine
> files.
>
> And so while I consider it to be out of the scope of the
> pristines-on-demand
> branch, I think that we might want to evaluate if this is something that
> should be a part of the next release.
Is it feasible and would it be beneficial to somehow decouple the hash code
type from the wc format version? Asking because IIRC the need for a format
bump to change hashes was one of the reasons it wasn't done a few years ago.
Cheers,
Nathan
Re: Getting to first release of pristines-on-demand feature (#525).
On 07 Dec 2022, Evgeny Kotkov wrote: The branch passes all tests in my Windows and Linux environments, in both --store-pristine=yes and =no modes. FYI, it passes all tests here too (on Debian GNU/Linux, up-to-date 'testing' distro). Attached file has details; there were some XFAILs, but no FAILs. Best regards, -Karl $ svn info | grep -E "^URL: " URL: https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-on-mwf $ svn status ? subversion/tests/libsvn_subr/task-test $ time make check [001/127] auth-test...success [002/127] authz-test..success [003/127] bit-array-test..success [004/127] cache-test..success [005/127] changes-testsuccess [006/127] checksum-test...success [007/127] client-test.success [008/127] compat-test.success [009/127] compress-test...success [010/127] config-test.success [011/127] conflict-data-test..success [012/127] conflicts-test..success [013/127] crypto-test.success [014/127] db-test.success [015/127] diff-diff3-test.success [016/127] dirent_uri-test.success [017/127] dump-load-test..success [018/127] entries-compat-test.success [019/127] error-code-test.success [020/127] error-test..success [021/127] filesize-test...success [022/127] fs-base-testsuccess [023/127] fs-fs-pack-test.success [024/127] fs-fs-private-test..
Re: Getting to first release of pristines-on-demand feature (#525).
On 07 Dec 2022, Evgeny Kotkov wrote: Evgeny Kotkov writes: I think that the `pristines-on-demand-on-mwf` branch is now ready for a merge to trunk. I could do that, assuming there are no objections. +1, and thank you. Now, I haven't had time to do a real code review -- my manager hat gets tighter every year -- so my "+1" is mainly a sign of enthusiasm for the feature, and of general trust in our test suite and in everyone who has worked on this. https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-on-mwf The branch includes the following: – Core implementation of the new mode where required pristines are fetched at the beginning of the operation. – A new --store-pristine=yes/no option for `svn checkout` that is persisted as a working copy setting. +1 to this UI. We can offer other gateways to this feature later, but this is a clean & simple way to start out. – An update for `svn info` to display the value of this new setting. Yay. – A standalone test harness that tests main operations in both --store-pristine modes and gets executed on every test run. – A new --store-pristine=yes/no option for the test suite that forces all tests to run with a specific pristine mode. Very nice. The branch passes all tests in my Windows and Linux environments, in both --store-pristine=yes and =no modes. W00t! While here, I would like to raise a topic of incorporating a switch from SHA1 to a different checksum type (without known collisions) for the new working copy format. This topic is relevant to the pristines-on-demand branch, because the new "is the file modified?" check relies on the checksum comparison, instead of comparing the contents of working and pristine files. And so while I consider it to be out of the scope of the pristines-on-demand branch, I think that we might want to evaluate if this is something that should be a part of the next release. Good point. Maybe worth a new thread? Best regards, -Karl
Re: Getting to first release of pristines-on-demand feature (#525).
Evgeny, Thanks so much for your hard work in pushing this project forward! I don't think I can contribute much in getting this merged to trunk (from lack of C experience and lack of time to dig into the inner workings), but I hope it can be completed! Kind regards, Daniel Sahlberg Den ons 7 dec. 2022 kl 18:10 skrev Evgeny Kotkov via dev < dev@subversion.apache.org>: > Evgeny Kotkov writes: > > > > IMHO, once the tests are ready, we could merge it and release > > > it to the world. > > > > Apart from the required test changes, there are some technical > > TODOs that remain from the initial patch and should be resolved. > > I'll try to handle them as well. > > I think that the `pristines-on-demand-on-mwf` branch is now ready for a > merge to trunk. I could do that, assuming there are no objections. > > > https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-on-mwf > > The branch includes the following: > – Core implementation of the new mode where required pristines are fetched > at the beginning of the operation. > – A new --store-pristine=yes/no option for `svn checkout` that is persisted > as a working copy setting. > – An update for `svn info` to display the value of this new setting. > – A standalone test harness that tests main operations in both > --store-pristine modes and gets executed on every test run. > – A new --store-pristine=yes/no option for the test suite that forces all > tests to run with a specific pristine mode. > > The branch passes all tests in my Windows and Linux environments, in both > --store-pristine=yes and =no modes. > > > While here, I would like to raise a topic of incorporating a switch from > SHA1 to a different checksum type (without known collisions) for the new > working copy format. This topic is relevant to the pristines-on-demand > branch, because the new "is the file modified?" check relies on the > checksum > comparison, instead of comparing the contents of working and pristine > files. > > And so while I consider it to be out of the scope of the > pristines-on-demand > branch, I think that we might want to evaluate if this is something that > should be a part of the next release. > > > Thanks, > Evgeny Kotkov >
Re: Getting to first release of pristines-on-demand feature (#525).
Evgeny Kotkov writes: > > IMHO, once the tests are ready, we could merge it and release > > it to the world. > > Apart from the required test changes, there are some technical > TODOs that remain from the initial patch and should be resolved. > I'll try to handle them as well. I think that the `pristines-on-demand-on-mwf` branch is now ready for a merge to trunk. I could do that, assuming there are no objections. https://svn.apache.org/repos/asf/subversion/branches/pristines-on-demand-on-mwf The branch includes the following: – Core implementation of the new mode where required pristines are fetched at the beginning of the operation. – A new --store-pristine=yes/no option for `svn checkout` that is persisted as a working copy setting. – An update for `svn info` to display the value of this new setting. – A standalone test harness that tests main operations in both --store-pristine modes and gets executed on every test run. – A new --store-pristine=yes/no option for the test suite that forces all tests to run with a specific pristine mode. The branch passes all tests in my Windows and Linux environments, in both --store-pristine=yes and =no modes. While here, I would like to raise a topic of incorporating a switch from SHA1 to a different checksum type (without known collisions) for the new working copy format. This topic is relevant to the pristines-on-demand branch, because the new "is the file modified?" check relies on the checksum comparison, instead of comparing the contents of working and pristine files. And so while I consider it to be out of the scope of the pristines-on-demand branch, I think that we might want to evaluate if this is something that should be a part of the next release. Thanks, Evgeny Kotkov
