Re: [PATCH] Fix "database is locked" error when committing during rep-cache.db verification
Denis Kovalchuk wrote on Sat, 02 May 2020 00:28 +0300:
> > So the failure mode is that rep-cache.db entries are not able to be
> > added while rep-cache.db is being verified. I am not convinced that
> > this is a problem.
>
> I think that this case leads to multiple problems:
> 1) Commits happening at the same time as verify will hang for the duration of
> sqlite busy timeout.
Yeah, they hang for 10 seconds:
[[[
subversion/libsvn_subr/sqlite.c|218 col 22| #define BUSY_TIMEOUT 1
subversion/libsvn_subr/config_file.c|1552 col 50| "### returning an error. The
default is 1, i.e. 10 seconds."NL
subversion/libsvn_subr/config_file.c|1554 col 27| "# busy-timeout = 1"
NL
]]]
Would it help to make this configurable? The BUSY_TIMEOUT pragma is
per-process so the admin can't just set it out of band, and the above
"busy-timeout" config file knob is used by libsvn_wc only, so this is
not currently configurable.
For that matter, now that build-repcache is a thing, why should commits
populate rep-cache synchronously at all? Why shouldn't we provide
a mode that says "svn_fs_commit_txn() won't populate the rep-cache for
you; you're expected to do it yourself via a post-commit hook"? That'll
sidestep the problem entirely. (Brane made a similar point a few days
ago.)
> 2) These commits will complete with a post-commit error.
There are other ways to address this. For example, whenever the
post-commit insertion to rep-cache.db fails, instead of reporting the
error to the client, we could record the error in the server log but not
report it to the client. After all, generally the client doesn't care
about that error and can't do anything to fix it.
>
Note: All the above suggestions, for both (1) and (2), would fix _all_
causes of (1) and (2), whereas your proposal would prevent (1) and (2)
only when they are caused by a concurrent «verify» operation, but not
otherwise.
(There are things other than «verify» that can cause the "post-commit FS
processing" rep-cache INSERT to time out and error out. For example,
that's known to happen to someone who makes a small commit that just
happens to occur right after a commit that has released the write lock
but hasn't finished inserting to rep-cache.db. I don't have the issue
number handy, sorry.)
> 3) No entries will be added to rep-cache.db. Unless fixed, following commits
> may work without deduplication.
Sure, but why is it not sufficient to run build-repcache afterwards?
> Repository verification can be a regular procedure and can take a long time
> for
> large repositories. And in that case the mentioned problems can also happen
> regularly.
>
> > The obvious workaround, in case someone runs into that, is for the
> > admin to run build-repcache afterwards. (Incidentally, we might want
> > have the "post-commit FS processing failed" error message namedrop
> > «svnadmin build-repcache» when the underlying error code indicates an
> > SQLite error.)
>
> I assume that the patch fixes the problem in such a way that it does not
> require any additional workarounds and does not worsen any other
> characteristics.
> At the same time, I would like to note that the workaround does not
> fix all problems. It fixes only 3) and only if it is called at the
> right time.
What do you mean, "at the right time"? Under what circumstances would
the following not suffice? —
set -e
old=`svnlook youngest r`
svnadmin verify r
svnadmin build-repcache r -r ${old}:HEAD
> > Yes, build-repcache will error out in this situation. Why is that a
> > problem?
>
> I think this is a problem for similar reasons. It may be unexpected that the
> read-only verify operation can lead to an error when another maintenance
> operation such as 'svnadmin build-repcache' is called.
Fair point, but the semantics of SQLite are what they are, and we have
to work with that. (Unless you propose to replace rep-cache.db by some
non-SQLite storage? Maybe SQLite isn't the right tool for the job after
all, even if it's the right tool for wc.db? Or, alternatively, can we
achieve finer-grained locking within SQLite?)
However, the foremost consideration for «svnadmin verify» is correctness.
Unintuitive behaviour can be dealt with via documentation, informative
error messages, and so on.
> To completely avoid failures, it may be necessary to separate
> operations by time, and this is not always possible.
When is it not possible to run «build-repcache» and «verify» sequentially?
> > What effect does the patch have on _correctness_ of verification? What
> > kinds of corruptions can be detected by the incumbent code but not with
> > your patch?
> >
> > Isn't there an alternative approach that does not affect the correctness
> > of verification as much as this approach?
>
> The patch does not change the verification process, only the process of
> fetching entries. In the previous approach entries were fetched during one
>
Re: [PATCH] Fix "database is locked" error when committing during rep-cache.db verification
> So the failure mode is that rep-cache.db entries are not able to be > added while rep-cache.db is being verified. I am not convinced that > this is a problem. I think that this case leads to multiple problems: 1) Commits happening at the same time as verify will hang for the duration of sqlite busy timeout. 2) These commits will complete with a post-commit error. 3) No entries will be added to rep-cache.db. Unless fixed, following commits may work without deduplication. Repository verification can be a regular procedure and can take a long time for large repositories. And in that case the mentioned problems can also happen regularly. > The obvious workaround, in case someone runs into that, is for the > admin to run build-repcache afterwards. (Incidentally, we might want > have the "post-commit FS processing failed" error message namedrop > «svnadmin build-repcache» when the underlying error code indicates an > SQLite error.) I assume that the patch fixes the problem in such a way that it does not require any additional workarounds and does not worsen any other characteristics. At the same time, I would like to note that the workaround does not fix all problems. It fixes only 3) and only if it is called at the right time. > Yes, build-repcache will error out in this situation. Why is that a problem? I think this is a problem for similar reasons. It may be unexpected that the read-only verify operation can lead to an error when another maintenance operation such as 'svnadmin build-repcache' is called. To completely avoid failures, it may be necessary to separate operations by time, and this is not always possible. > What effect does the patch have on _correctness_ of verification? What > kinds of corruptions can be detected by the incumbent code but not with > your patch? > > Isn't there an alternative approach that does not affect the correctness > of verification as much as this approach? The patch does not change the verification process, only the process of fetching entries. In the previous approach entries were fetched during one large query and now they are fetched in small batches. In this way: 1) If rep-cache.db is not changed during its verification, the new approach should be equivalent to the previous one. 2) If new entries are added to the rep-cache.db during its verification, the new approach has a guarantee that all entries that existed at the time of the call of 'svnadmin verify' will be verified. So I think that it should not affect the correctness of verification. Regards, Denis Kovalchuk
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
On Fri, May 1, 2020 at 4:20 PM Daniel Shahaf wrote: > Mark Phippard wrote on Fri, 01 May 2020 18:26 +00:00: > > > Since we reached the 6 month mark for 1.13 yesterday, that means its > > support will continue until 1.14 is released at which point it is EOL. > > Can we dig down on this point a bit? > > On a macro scale, switching from "we support 1.9, 1.10, 1.13" to "we > support 1.10, 1.14" is fine. No argument about that. > > However, once you dig down into the details, how are administrators of > 1.13.x installations expected to upgrade to 1.14.x without running an > unsupported version at any point? > > Presumably we don't expect 1.13.x users to run 1.14.0-rc2 in > production — our RC announcement templates are quite clear about that — > so I infer that we expect 1.13.x users to upgrade to 1.14.0 soon after > its release. > > All I'm asking is that we quantify "soon". > > For example, if we say users of 1.13.x are expected to upgrade to 1.14.0 > within N days of the latter's release, that would mean that we promise not > to do a 1.14.1 security release within those N days *unless* it's > accompanied by a 1.13.1 release with a backport of the same fix. > > I'm not asking to set N to a large value. I'm just proposing that we > document _some_ value, even if it's a small one, so users would know > when to upgrade by. > I assume users upgrade when they have a reason to. Once 1.14 is released our "policy" is that there will not be any additional 1.13 releases. Our community always has the option of still creating a release if we feel it is warranted and there is enough support for backporting/signing/RM the release but we were clear what users should expect. There are already several fixes in 1.14. If those are important to someone then they will need to upgrade. If not, they can do it when they choose. If users were concerned about our support then they could have stayed on 1.10 which still has 2 more years of support. Mark
Releasing unidiffs (was: Re: Grace period for 1.13 users to upgrade to 1.14?)
Julian Foad wrote on Fri, 01 May 2020 15:58 +: > 1 May 2020 16:39:36 Nathan Hartman : > > > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf < d...@daniel.shahaf.name > > > wrote: > > > > > > > danie...@apache.org wrote on Thu, 30 Apr 2020 16:21 -: > > > > > > > > I just copied the text we use for 1.9, but there's a distinction: users > > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA, > > > whereas users of 1.13 have not. So, should we promise some sort of > > > grace period for users of 1.13.x — i.e., a period following the release > > > of 1.14.0 during which we'll still fix security bugs in 1.13.0? > > > > > > Before I can offer an opinion on that, I have to ask: If that > > scenario actually occurs, where a security issue is discovered in a > > release line very soon after it goes EOL, … then there doesn't have to be a fix at all. By definition, once a line goes EOL, we don't promise to fix bugs in it; the community's collective stance on bugs becomes "Please upgrade to a supported release line". Even then, people can still fix individual bugs in older lines, if that's what scratches their personal itches. See r873205 for example. That bug was found when only 1.4.x and 1.5.x were supported, but people backported it all the way back to 1.0.x (!). We didn't roll a 1.0.x release afterwards, but the fix was backported by us for downstream packagers' benefit. This way, packagers don't have to resolve conflicts by themselves and users don't have to contend with a minor version upgrade (with the entailed risk of running into regressions, particularly when upgrading to a .0 release). Furthermore, we can choose to issue a fix even if we didn't promise to. (The community's support promises are a minimum, not a maximum.) And now, to your question: > > does the fix have to be an actual *release* with all the process > > that implies, or can it just be a (signed) patch? Both. When we have code we expect users to run, it's in our interest to issue it as a proper release, in order for the legal shield to apply to it; and I don't believe there's anything preventing us from releasing unidiffs rather than (or alongside) compressed tarballs. We would still have to vote on the unidiff, sign it, etc., just like any other release artifact. However, creating a release doesn't require using release.py, creating tarballs, creating a tag, incrementing SVN_VER_PATCH, or holding the vote on any particular mailing list. The hard minimum for a release is a PMC vote that blesses a particular artifact as a release. (By the way, that's one of the few cases in which the distinction between "full committer" and "PMC member" matters. The former is a community status, like "patch manager"; the latter is a legal construct.) > Re. issuing fixes as patches, I think there's no precedent and no > grounds for doing so this time. The option of doing so in future for > the general case should be raised in a separate thread. Cheers, Daniel
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Mark Phippard wrote on Fri, 01 May 2020 18:26 +00:00: > On Fri, May 1, 2020 at 2:17 PM Daniel Shahaf wrote: > > I'm not asking for special treatment or for changing the policy. I'm > > asking to clarify the policy for the general case of the period of time > > immediately following a 1.(x+1).0 release, where the 1.x line was a > > non-LTS release. (In this specific instance x+1 is an LTS release, but > > that's a red herring.) > > The way I read and understood the policy the support is time based. A > regular release is supported for 6 months from its initial release date > or until the next release is available. If the next release came out 5 > months later then it would still get 6 months of support. If the next > release came out 9 months later then it would get 9 months of support. > Thanks for clarifying this. That's my understanding too. > Since we reached the 6 month mark for 1.13 yesterday, that means its > support will continue until 1.14 is released at which point it is EOL. Can we dig down on this point a bit? On a macro scale, switching from "we support 1.9, 1.10, 1.13" to "we support 1.10, 1.14" is fine. No argument about that. However, once you dig down into the details, how are administrators of 1.13.x installations expected to upgrade to 1.14.x without running an unsupported version at any point? Presumably we don't expect 1.13.x users to run 1.14.0-rc2 in production — our RC announcement templates are quite clear about that — so I infer that we expect 1.13.x users to upgrade to 1.14.0 soon after its release. All I'm asking is that we quantify "soon". For example, if we say users of 1.13.x are expected to upgrade to 1.14.0 within N days of the latter's release, that would mean that we promise not to do a 1.14.1 security release within those N days *unless* it's accompanied by a 1.13.1 release with a backport of the same fix. I'm not asking to set N to a large value. I'm just proposing that we document _some_ value, even if it's a small one, so users would know when to upgrade by. Cheers, Daniel (And again, this has nothing to do with 1.14 being LTS. It's been an issue since the first time a 6-month-support minor line was obsoleted by a newer minor line.)
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
On Fri, May 1, 2020 at 2:17 PM Daniel Shahaf wrote: > Mark Phippard wrote on Fri, 01 May 2020 11:49 -0400: > > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf > > wrote: > > > > > danie...@apache.org wrote on Thu, 30 Apr 2020 16:21 -: > > > > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30 > > > 16:21:48 2020 > > > > @@ -1330,6 +1330,20 @@ if they occur. > > > > + > > > > +Subversion 1.13.x is end of life > > > > + > > > +title="Link to this section"> > > > > + > > > > + > > > > +The Subversion 1.13.x line is end of life (EOL). > > > > +This doesn't mean that your 1.13 installation is doomed; if it works > > > > +well and is all you need, that's fine. "End of life" just means > we've > > > > +stopped accepting bug reports against 1.13.x versions, and will not > > > > +make any more 1.13.x releases. > > > > > > I just copied the text we use for 1.9, but there's a distinction: users > > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA, > > > whereas users of 1.13 have not. So, should we promise some sort of > > > grace period for users of 1.13.x — i.e., a period following the release > > > of 1.14.0 during which we'll still fix security bugs in 1.13.0? > > > > > > Granted, 1.13 was a regular release and was only promised to be > > > supported for six months (or until 1.14.0) in the first place, so the > > > grace period needn't be long. > > > > > > > My recollection is that we gave 1.9 special treatment because 1.10 was > the > > first release with the new LTS policy in place. So we said we would > handle > > 1.9 the same way we would have prior to the new policy. I do not see any > > reason to give 1.13 special treatment. We created the LTS policy and we > > should plan on sticking to it. It is not like we do not have the option > of > > doing whatever we want when and if a security issue actually crops up. > > I'm not asking for special treatment or for changing the policy. I'm > asking to clarify the policy for the general case of the period of time > immediately following a 1.(x+1).0 release, where the 1.x line was a > non-LTS release. (In this specific instance x+1 is an LTS release, but > that's a red herring.) > The way I read and understood the policy the support is time based. A regular release is supported for 6 months from its initial release date or until the next release is available. If the next release came out 5 months later then it would still get 6 months of support. If the next release came out 9 months later then it would get 9 months of support. Since we reached the 6 month mark for 1.13 yesterday, that means its support will continue until 1.14 is released at which point it is EOL. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
Mark Phippard wrote on Fri, 01 May 2020 11:49 -0400: > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf > wrote: > > > danie...@apache.org wrote on Thu, 30 Apr 2020 16:21 -: > > > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30 > > 16:21:48 2020 > > > @@ -1330,6 +1330,20 @@ if they occur. > > > + > > > +Subversion 1.13.x is end of life > > > + > > +title="Link to this section"> > > > + > > > + > > > +The Subversion 1.13.x line is end of life (EOL). > > > +This doesn't mean that your 1.13 installation is doomed; if it works > > > +well and is all you need, that's fine. "End of life" just means we've > > > +stopped accepting bug reports against 1.13.x versions, and will not > > > +make any more 1.13.x releases. > > > > I just copied the text we use for 1.9, but there's a distinction: users > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA, > > whereas users of 1.13 have not. So, should we promise some sort of > > grace period for users of 1.13.x — i.e., a period following the release > > of 1.14.0 during which we'll still fix security bugs in 1.13.0? > > > > Granted, 1.13 was a regular release and was only promised to be > > supported for six months (or until 1.14.0) in the first place, so the > > grace period needn't be long. > > > > My recollection is that we gave 1.9 special treatment because 1.10 was the > first release with the new LTS policy in place. So we said we would handle > 1.9 the same way we would have prior to the new policy. I do not see any > reason to give 1.13 special treatment. We created the LTS policy and we > should plan on sticking to it. It is not like we do not have the option of > doing whatever we want when and if a security issue actually crops up. I'm not asking for special treatment or for changing the policy. I'm asking to clarify the policy for the general case of the period of time immediately following a 1.(x+1).0 release, where the 1.x line was a non-LTS release. (In this specific instance x+1 is an LTS release, but that's a red herring.) If we want to leave it as unspecified, I'll defer to consensus. And, incidentally, I think we can likewise leave unspecified the policy for which minor versions of Python 3 we'll support, thereby resolving a (user-facing) TODO in the 1.14 release notes. Cheers, Daniel
Re: [PATCH] Fix variable declarations in swigutil_py.c
Branko Čibej wrote on Fri, 01 May 2020 15:24 +0200: > On 01.05.2020 12:18, Jun Omae wrote: > > Hi, > > > > I got the following syntax errors while building swigutil_py.c in > > trunk with Visual Studio 2008 (VC9). > [...] > > It seems that several variable declarations are not at start of block. > > The declarations lead the syntax errors with Visual Studio 2008. > > > > After attached patch, the errors go away. > > > r1877259, thanks! Backport needed? If so, my +0.
Re: Problems running testsuite on Windows with Python 3
On 2020/04/23 2:05, Yasuhito FUTATSUKI wrote:
> On 2020/04/22 23:04, Johan Corveleyn wrote:
>> On Wed, Apr 22, 2020 at 3:50 PM Yasuhito FUTATSUKI
>> wrote:
>
>>> ... and what is worse, at least
>>>
FAIL: merge_tests.py 34: conflict markers should match the file's eol
style
>>>
>>> this one seems to be broken even with Python 2.7, on Windows.
>>> (I'll post about it later).
>>
>> That's strange. It does succeed on my system when running with Python
>> 2.7.17. I had "All successful" test runs for [fsfs] x [ra_local,
>> ra_serf, ra_svn].
>
> Yes, I don't doubt this test is passed on Windows with Python 2.7,
> but I doubt this test does not check just what we want to check.
>
> As far as I read the description of the test and about KEEP_EOL_STYLE
> option introduced in r1743445.
>
> merge_tests.py (merge_conflict_markers_matching_eol):
> [[[
> # eol-style handling during merge with conflicts, scenario 1:
> # when a merge creates a conflict on a file, make sure the file and files
> # r, r and .mine are in the eol-style defined for that file.
> ]]]
>
> So I think comparion of expected and actual should be done without
> eol-style translation. However it try to check with translation on
> Windows environment.
It seems following tests are EOL style sensitive, but they didn't
check without strict EOL style on Windows:
merge_tests.merge_conflict_markers_matching_eol
merge_tests.merge_eolstyle_handling
patch_tests.patch_no_svn_eol_style
patch_tests.patch_with_svn_eol_style
patch_tests.patch_with_svn_eol_style_uncommitted
update_tests.conflict_markers_matching_eol
update_tests.update_eol_style_handling
I've not check that each tests depend that native EOL is '\n' or not.
However, I think if some tests depend on it, other test cases for
those aims are needed on Windows, or at least explicitly skip the tests
on Windows to clarify that those tests check nothing for the aims.
The updated patch attached only make these tests EOL style sensitive
(and relax check of EOL on Python 2 if keep_eol_style optional
parameter is not specified).
Cheers,
--
Yasuhito FUTATSUKI /
Fix eol style treatment in command tests on Windows.
[in subversion/tests/cmdline]
* merge_tests.py (merge_conflict_markers_matching_eol,
merge_eolstyle_handling),
* patch_tests.py (patch_no_svn_eol_style,
patch_with_svn_eol_style,
patch_with_svn_eol_style_uncommitted),
* update_tests.py (conflict_markers_matching_eol,
update_eol_style_handling):
Specify keep_eol_style = True evne if platform is Windows.
* merge_tests.py (merge_conflict_markers_matching_eol),
* patch_tests.py (patch_with_svn_eol_style,
patch_with_svn_eol_style_uncommitted),
* conflict_markers_matching_eol):
Switch per platform eol value for 'native' svn:eol-style
* svntest/wc.py (State.from_wc):
Use io.open() explicitly to specify 'newline' parameter for universal newline,
even on Python 2. With this change, '\r' end of line chracters in files
are also translated to '\n' if keep_eol_style=False (or unspicified) on
Python 2.
Index: subversion/tests/cmdline/merge_tests.py
===
--- subversion/tests/cmdline/merge_tests.py (revision 1876908)
+++ subversion/tests/cmdline/merge_tests.py (working copy)
@@ -3323,16 +3323,12 @@
mu_path = sbox.ospath('A/mu')
- # CRLF is a string that will match a CRLF sequence read from a text file.
- # ### On Windows, we assume CRLF will be read as LF, so it's a poor test.
if os.name == 'nt':
-crlf = '\n'
+native_nl = '\r\n'
else:
-crlf = '\r\n'
+native_nl = '\n'
+ crlf = '\r\n'
- # Strict EOL style matching breaks Windows tests at least with Python 2
- keep_eol_style = not svntest.main.is_os_windows()
-
# Checkout a second working copy
wc_backup = sbox.add_wc_path('backup')
svntest.actions.run_and_verify_svn(None, [], 'checkout',
@@ -3349,8 +3345,8 @@
path_backup = os.path.join(wc_backup, 'A', 'mu')
# do the test for each eol-style
- for eol, eolchar in zip(['CRLF', 'CR', 'native', 'LF'],
- [crlf, '\015', '\n', '\012']):
+ for eol, eolchar in zip(['CRLF', 'CR','native', 'LF'],
+ [crlf, '\015', native_nl, '\012']):
# rewrite file mu and set the eol-style property.
svntest.main.file_write(mu_path, "This is the file 'mu'."+ eolchar, 'wb')
svntest.main.run_svn(None, 'propset', 'svn:eol-style', eol, mu_path)
@@ -3445,7 +3441,7 @@
expected_backup_disk,
expected_backup_status,
expected_backup_skip,
- keep_eol_style=keep_eol_style)
+ keep_eol_style=True)
# cleanup for next run
svntest.main.run_svn(None, 'revert', '-R', wc_backup)
Re: Grace period for 1.13 users to upgrade to 1.14?
In my opinion, although it's "nice" when everyone has clarity on all details of the process, it's just not important to decide this level of detail in advance. It's a fuzzy line and we'll make a reasonable decision if it happens, which it likely won't. Re. issuing fixes as patches, I think there's no precedent and no grounds for doing so this time. The option of doing so in future for the general case should be raised in a separate thread. - Julian 1 May 2020 16:39:36 Nathan Hartman : > On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf < d...@daniel.shahaf.name > > wrote: > > > > danie...@apache.org wrote on Thu, 30 Apr 2020 16:21 -: > > > > > I just copied the text we use for 1.9, but there's a distinction: users > > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA, > > whereas users of 1.13 have not. So, should we promise some sort of > > grace period for users of 1.13.x — i.e., a period following the release > > of 1.14.0 during which we'll still fix security bugs in 1.13.0? > > > Before I can offer an opinion on that, I have to ask: If that scenario > actually occurs, where a security issue is discovered in a release line very > soon after it goes EOL, does the fix have to be an actual *release* with all > the process that implies, or can it just be a (signed) patch? > > > Nathan > > > > > > >
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf wrote: > danie...@apache.org wrote on Thu, 30 Apr 2020 16:21 -: > > +++ subversion/site/publish/docs/release-notes/1.14.html Thu Apr 30 > 16:21:48 2020 > > @@ -1330,6 +1330,20 @@ if they occur. > > + > > +Subversion 1.13.x is end of life > > + > +title="Link to this section"> > > + > > + > > +The Subversion 1.13.x line is end of life (EOL). > > +This doesn't mean that your 1.13 installation is doomed; if it works > > +well and is all you need, that's fine. "End of life" just means we've > > +stopped accepting bug reports against 1.13.x versions, and will not > > +make any more 1.13.x releases. > > I just copied the text we use for 1.9, but there's a distinction: users > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA, > whereas users of 1.13 have not. So, should we promise some sort of > grace period for users of 1.13.x — i.e., a period following the release > of 1.14.0 during which we'll still fix security bugs in 1.13.0? > > Granted, 1.13 was a regular release and was only promised to be > supported for six months (or until 1.14.0) in the first place, so the > grace period needn't be long. > My recollection is that we gave 1.9 special treatment because 1.10 was the first release with the new LTS policy in place. So we said we would handle 1.9 the same way we would have prior to the new policy. I do not see any reason to give 1.13 special treatment. We created the LTS policy and we should plan on sticking to it. It is not like we do not have the option of doing whatever we want when and if a security issue actually crops up. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: Grace period for 1.13 users to upgrade to 1.14? (was: svn commit: r1877222 - /subversion/site/publish/docs/release-notes/1.14.html)
On Thu, Apr 30, 2020 at 12:47 PM Daniel Shahaf wrote: > danie...@apache.org wrote on Thu, 30 Apr 2020 16:21 -: > I just copied the text we use for 1.9, but there's a distinction: users > of 1.9 have had time to upgrade to 1.10 before 1.14.0 becomes GA, > whereas users of 1.13 have not. So, should we promise some sort of > grace period for users of 1.13.x — i.e., a period following the release > of 1.14.0 during which we'll still fix security bugs in 1.13.0? Before I can offer an opinion on that, I have to ask: If that scenario actually occurs, where a security issue is discovered in a release line very soon after it goes EOL, does the fix have to be an actual *release* with all the process that implies, or can it just be a (signed) patch? Nathan
Re: [PATCH] Fix variable declarations in swigutil_py.c
On 01.05.2020 12:18, Jun Omae wrote: > Hi, > > I got the following syntax errors while building swigutil_py.c in > trunk with Visual Studio 2008 (VC9). [...] > It seems that several variable declarations are not at start of block. > The declarations lead the syntax errors with Visual Studio 2008. > > After attached patch, the errors go away. r1877259, thanks! -- Brane
[PATCH] Fix variable declarations in swigutil_py.c
Hi,
I got the following syntax errors while building swigutil_py.c in trunk with
Visual Studio 2008 (VC9).
"C:\usr\src\subversion\trunk\subversion_vcnet.sln" (__MORE__;__SWIG_PYTHON__
target) (1) ->
(Libraries\Swig\svn_swig_py target) ->
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1183):
error C2143: syntax error : missing ';' before 'const'
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1189):
error C2065: 'propval' : undeclared identifier
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1189):
error C4022: 'apr_hash_set' : pointer mismatch for actual parameter 4
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1195):
error C2143: syntax error : missing '{' before '*'
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1197):
error C2371: 'svn_swig_py_mergeinfo_from_dict' : redefinition; different basic
types
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1227):
error C2143: syntax error : missing ';' before 'const'
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1234):
error C2065: 'ranges' : undeclared identifier
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1241):
error C2065: 'ranges' : undeclared identifier
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1241):
error C4022: 'apr_hash_set' : pointer mismatch for actual parameter 4
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1247):
error C2143: syntax error : missing '{' before '*'
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1249):
error C2371: 'svn_swig_py_proparray_from_dict' : redefinition; different basic
types
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1326):
error C2275: 'svn_string_t' : illegal use of this type as an expression
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1326):
error C2065: 'propval' : undeclared identifier
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1332):
error C2065: 'propval' : undeclared identifier
..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(1332):
error C4022: 'apr_hash_set' : pointer mismatch for actual parameter 4
It seems that several variable declarations are not at start of block.
The declarations lead the syntax errors with Visual Studio 2008.
After attached patch, the errors go away.
--
Jun Omae (大前 潤)
* subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
Move variable declarations at start of block to fix syntax errors with VC9.
Index: subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
===
--- subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
(revision 1876859)
+++ subversion/bindings/swig/python/libsvn_swig_py/swigutil_py.c
(working copy)
@@ -1171,6 +1171,7 @@
PyObject *key = PyList_GetItem(keys, i);
PyObject *value = PyDict_GetItem(dict, key);
const char *propname = make_string_from_ob(key, pool);
+ const char *propval;
if (!propname)
{
if (!PyErr_Occurred())
@@ -1180,7 +1181,7 @@
Py_DECREF(keys);
return NULL;
}
- const char *propval = make_string_from_ob_maybe_null(value, pool);
+ propval = make_string_from_ob_maybe_null(value, pool);
if (PyErr_Occurred())
{
Py_DECREF(keys);
@@ -1215,6 +1216,7 @@
PyObject *key = PyList_GetItem(keys, i);
PyObject *value = PyDict_GetItem(dict, key);
const char *pathname = make_string_from_ob(key, pool);
+ const svn_rangelist_t *ranges;
if (!pathname)
{
if (!PyErr_Occurred())
@@ -1224,7 +1226,7 @@
Py_DECREF(keys);
return NULL;
}
- const svn_rangelist_t *ranges = svn_swig_py_seq_to_array(value,
+ ranges = svn_swig_py_seq_to_array(value,
sizeof(const svn_merge_range_t *),
svn_swig_py_unwrap_struct_ptr,
svn_swig_TypeQuery("svn_merge_range_t *"),
@@ -1314,6 +1316,7 @@
PyObject *key = PyList_GetItem(keys, i);
PyObject *value = PyDict_GetItem(dict, key);
const char *propname = make_string_from_ob(key, pool);
+ svn_string_t *propval;
if (!propname)
{
if (!PyErr_Occurred())
@@ -1323,7 +1326,7 @@
Py_DECREF(keys);
return NULL;
}
- svn_string_t *propval = make_svn_string_from_ob_maybe_null(value, pool);
+ propval = make_svn_string_from_ob_maybe_null(value, pool);
if (PyErr_Occurred())
{
Py_DECREF(keys);
[PATCH] Fix unable to build with Visual Studio 2008
Hi, I tried to build Subversion 1.10.x and trunk with Visual Studio 2008 for Python (2.7) bindings, however I got the following error from `msbuild subversion_vcnet.sln /t:__MORE__ /p:Configuration=Release`. "C:\usr\src\subversion\1.10.x\subversion_vcnet.sln" (__MORE__;__SWIG_PYTHON__ target) (1) -> (Tests\conflicts-test target) -> ..\..\..\subversion\tests\libsvn_wc\utils.c : fatal error C1033: cannot open program database 'c:\usr\src\subversion\1.10.x\release\subversion\tests\libsvn_client\libsvn_wc\test_conflicts-..\libsvn_wc.pdb' I think the following line in vcnet_vcproj.ezt is incorrect. The line is introduced in r873230. ProgramDataBaseFileName="$(IntDir)/[sources.reldir]/[target.proj_name]-[sources.reldir].pdb"/> After attached patch, the error goes away and build successfully. -- Jun Omae (大前 潤) * build/generator/vcnet_vcproj.ezt Fix "cannot open program database" error while building with Visual Studio 2008. Index: build/generator/templates/vcnet_vcproj.ezt === --- build/generator/templates/vcnet_vcproj.ezt (revision 1876908) +++ build/generator/templates/vcnet_vcproj.ezt (working copy) @@ -147,7 +147,7 @@ + ProgramDataBaseFileName="$(IntDir)/[sources.reldir]/[target.proj_name].pdb"/> [end][end][end][end]
