make it safe, and
it's opt-in, that might be acceptable.
There's one (kinda BIG) caveat: supposing there's a discussion and a design
and consensus that this feature request is a good idea, we'd still need one
or more volunteers to develop the feature and champion it through to a
release. Being a volunteer-driven project, that is usually the biggest
challenge around here.
Cheers,
Nathan
esolve most of them
quite quick.
I guess you mean the TODOs in the i525 user guide. (The draft release notes
have only 5 TODOs, of which 4 are in the compatibility table and 1 is a
reminder to link to the i525 user guide.)
I haven't gone through the user guide yet but I'll try to do it soon.
Cheers,
Nathan
; --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
>
Hi,
Is there a reason why the patch hasn't been committed? (I only gave it a
cursory look. I haven't studied it in detail.)
Cheers,
Nathan
To give a *good* answer here, I would need to actually look at the code.
But my initial reaction is:
Maybe the failing test can be modified to contact Subversion's Subversion
repository instead? (Still gated by is_remote_http_connection_allowed.)
> Cheers,
> Daniel
>
>
> [1]
> https://github.blog/news-insights/product-news/sunsetting-subversion-support/
>
Cheers,
Nathan
On Fri, Jan 31, 2025 at 6:08 AM Daniel Sahlberg
wrote:
>
> Den tors 30 jan. 2025 kl 23:17 skrev Nathan Hartman
> :
>>
>> [...]
>>
>> Committed to the staging site in r1923465:
>>
>> https://subversion-staging.apache.org/reporting-issues.ht
On Tue, Jan 28, 2025 at 1:03 PM C. Michael Pilato wrote:
>
> On Tue, Jan 28, 2025 at 10:51 AM Nathan Hartman
> wrote:
>>
>> >From time to time we get account requests for Jira from members of the
>> community. There is such a request now.
>>
>> Histor
always direct them to [2], though if someone is helpful enough
to justify having their own Jira account, we might consider inviting
them to be committers instead.)
References:
[1] https://subversion.apache.org/reporting-issues.html
[2] https://subversion.apache.org/docs/community-guide/issues.html#issues
Thoughts?
Cheers,
Nathan
o nitpick! :-)
By the way, did it give you any trouble with this catch-up? I had a
rather interesting time with r1922147 so I hope merges in the site are
easier now...
Cheers,
Nathan
On Mon, Dec 16, 2024 at 1:17 PM Timofei Zhakov wrote:
(snip)
> Hi Nathan,
>
> Thanks for clarifying your thoughts.
>
> As I am understanding that, you are looking forward to make the xpatches
> applying through the svn_client_patch() function, which is currently working
>
On Sun, Dec 15, 2024 at 4:39 PM Nathan Hartman wrote:
> And, yes, there is a way to make a stream from a apr_file_t:
>
> /* Helper function that creates a stream from an APR file. */
> static svn_stream_t *
> make_stream_from_apr_file(apr_file_t *file,
>
On Fri, Dec 13, 2024 at 5:01 PM Nathan Hartman wrote:
>
> On Fri, Dec 13, 2024 at 9:06 AM Timofei Zhakov wrote:
> >
> > (snip)
> >
> >>
> >> I think this makes sense. That's what I wrote in a (rough draft) 'svn
> >> help patch' t
strong
feelings in the past but I'm leaving them in the past to focus on the
greater good. I hope that can be the theme.
[1] https://subversion.apache.org/roadmap.html#release-planning
Please share your thoughts...
Nathan
7;,
>> > since it's very unusual to begin a log-message with this line, but we
>> > should take it in mind.
>> >
>> > Additionally, we may add an argument to the `svn patch` command, so users
>> > will be able to specify the kind explicitly,
On Wed, Dec 11, 2024 at 11:27 AM Timofei Zhakov wrote:
>
> On Tue, Nov 26, 2024 at 11:15 PM Daniel Sahlberg
> wrote:
>>
>> Hi,
>>
>> Thanks for the detailed explanation.
>>
>> Offering some small inputs, but basically I think Nathan has made very goo
: https://github.com/apache/subversion/actions/runs/12124369156
>
> With regards,
> GitHub Actions via GitBox
The error is:
Run ctest --output-on-failure --verbose -C Release --jobs 16
CMake Error: Unknown argument: --jobs
Should be --parallel or
On Mon, Dec 2, 2024 at 12:53 PM Timofei Zhakov wrote:
>
> On Mon, Dec 2, 2024 at 6:47 PM Nathan Hartman
> wrote:
> >
> > On Mon, Dec 2, 2024 at 12:40 PM GitBox wrote:
> > >
> > >
> > > The GitHub Actions job "CMake" on subversi
h?
I tried to follow along but admittedly between the commit mails and
GHA notifications I got a little bit lost. :-)
I recommend to amend the log for the revision that fixed it... perhaps
something like:
[[[
Note from future: This fixes:
'FAIL: merge_tests.py 129: merge with added subtrees with mergeinfo'
which was accidentally broken on the apply-processor branch during
refactoring.
]]]
Congrats on finding that!
Cheers,
Nathan
On Thu, Nov 28, 2024 at 1:43 AM Daniel Sahlberg
wrote:
> Den ons 27 nov. 2024 kl 08:40 skrev Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com>:
>
>> Den ons 27 nov. 2024 kl 06:42 skrev Nathan Hartman <
>> hartman.nat...@gmail.com>:
>>
> A little while a
nd supported
release branches (currently 1.14.x) to draw attention to real
problems. :-)
(Not sure if this is already the case but ideally it should notify
once if the build breaks and once again when the build is fixed, but
not notify for each build.)
Hope this helps, somehow...
Nathan
owing up in the browser as expected.
Since r1922147 was kind of a hairy manual merge, I'm tempted to think
something got messed up there, but I don't see anything wrong in the
diff.
Any ideas?
Thanks,
Nathan
iff'.\n"
"\n"), N_(
+ " An xpatch file can be produced with the 'svn diff --xpatch' command.\n"
+ " This patch format is specific to Subversion and can represent all\n"
+ " types of working copy changes. It is applied with three-way merging\n"
+ " and conflict resolution.\n"
+ "\n"), N_(
" Changes listed in the patch will either be applied or rejected.\n"
" If a change does not match at its exact line offset, it may
be applied\n"
" earlier or later in the file if a match is found elsewhere for the\n"
" surrounding lines of context provided by the patch.\n"
" A change may also be applied with fuzz, which means that one\n"
" or more lines of context are ignored when matching the change.\n"
" If no matching context can be found for a change, the change
conflicts\n"
" and will be written to a reject file with the extension
.svnpatch.rej.\n"
"\n"), N_(
" For each patched file a line will be printed with characters
reporting\n"
]]]
The last part of 'svn help patch' (not shown) is only applicable to
unidiff (and git unidiff) patches so needs a small edit to clarify
that. I tried various phrasings but wasn't happy with any of them so
far.
I didn't do it for 'svn help merge' text yet.
If you'd like, I'll be happy to draft 'svn help' text, for 'svn diff'
and whichever of 'svn patch' or 'svn merge' ends up being the command.
Thoughts, corrections, alternative ideas welcome!
References:
[1] danielsh's message to dev@ on 24 Nov 2024:
https://lists.apache.org/thread/gywjpqyxvryo08wtq1t0232v6vdf94c1
Cheers,
Nathan
We got a notification! Out of curiosity did it really need to be triggered
by Humbedooh or does it always say that?
On Tue, Nov 26, 2024 at 10:36 AM GitBox wrote:
>
> The GitHub Actions job "Build and Test Subversion using autoconf build
> system" on subversion.git has failed.
> Run started by G
On Tue, Nov 26, 2024 at 6:45 AM Nathan Hartman
wrote:
> On Tue, Nov 26, 2024 at 6:27 AM Timofei Zhakov wrote:
>
>> On Tue, Nov 26, 2024 at 11:11 AM Daniel Sahlberg <
>> daniel.l.sahlb...@gmail.com> wrote:
>>
>>> Den mån 25 nov. 2024 kl 15:10 skrev :
>
niquify the test repos
and working copies, perhaps by putting them in a subdirectory named for the
test, so (just picking something by random) merge test #123 might have its
test data in ../merge_tests/123/ Then if multiple tests run
simultaneously they shouldn't bother each other.
Of course, how that would happen is another matter. Perhaps the test driver
could record which test it is about to run and the repo and wc creation
could use that information?
Cheers,
Nathan
nges.
Also with the way unidiff patches are applied, we instruct the user (in
'svn help patch') to find the revision at which the patch was made, update
to that revision, apply the patch, and then update to HEAD to get merging
and conflict resolution.
Since the new patch format will be able to represent changes more fully,
they will be able to be applied to a working copy tree that has had
potentially a substantial amount of other changes since it would benefit
from 3-way merge and conflict resolution.
I'm +1 for having something like this.
I have written some specific thoughts about it which I plan to share soon...
Cheers,
Nathan
log.
This sounds wonderful!
Admittedly I'm not familiar enough with CTest to review this right now, but
this is a great excuse to become familiar with it. I'll try to get set up
for that sometime this week and let you know how it goes...
Thanks for all the good work on CMake support.
Cheers,
Nathan
e more information as well as links to
additional CWIKI pages:
https://subversion.apache.org/docs/release-notes/1.14.html#shelving
Would your proposed new feature make it possible to implement shelving that
has the advantages of v3 (can shelve/unshelve any committable changes, with
proper merging and conflict resolution) while using minimal storage space
by storing its data somewhat like v1 (in 'xpatch' files)? Would it make
sense to do so?
Cheers,
Nathan
uild on Linux, basically the same we
> have on GHA (but GHA covers both Linux and Windows and multiple
> configurations).
We need testing for the currently supported release branch(es) as well
as trunk. At least that's what we had before the Buildbot upgrade of a
few years ago. I tried to tackle that some time back and wasn't
successful. Currently Buildbot is only testing trunk.
Let me know if I need to request Infra to set up the email notifications...
Thanks,
Nathan
on. Apart from properly recording renames, this is a main
> feature that makes me use it and not just give in to git everywhere.
> Subversion is my versioned file system.
>
> I know I could do a repository branch for each instance that now is a
> working copy, but this would be unnecessary noise for my setup, and
> also I do not want to encourage actual divergence of the versioned
> contents, only give each working copy its selection of parts of the
> tree.
>
>
> Alrighty then,
>
> Thomas
>
> --
> Dr. Thomas Orgis
> HPC @ Universität Hamburg
Hope this helps...
Cheers,
Nathan
for
>> maintainers to contribute. To graft hwright@'s phrasing, the steps
>> for a maintainer to edit STATUS should be "1. Profit!". :)
>
>
+1 to that!
Cheers,
Nathan
On Wed, Nov 20, 2024 at 9:22 AM Daniel Shahaf wrote:
>
> Nathan Hartman wrote on Tue, 19 Nov 2024 16:00 +00:00:
> > Looking through the backports stuff in tools/dist, currently it's a
> > little bit messy. I wonder if things can be simplified with a minimal
> > amou
for errors. I think it could be
implemented as a dry-run of 'merge-approved'.
If there are maintainers who prefer nominating and voting
interactively, there can be two additional subcommands:
backport.py nominate
backport.py vote
but we don't need to implement these if there isn't interest in using
them.
Thoughts?
Nathan
On Sun, Oct 20, 2024 at 7:17 AM Daniel Sahlberg
wrote:
> Den sön 20 okt. 2024 kl 07:07 skrev Nathan Hartman <
> hartman.nat...@gmail.com>:
>
>> On Sat, Oct 19, 2024 at 4:18 PM Daniel Sahlberg <
>> daniel.l.sahlb...@gmail.com> wrote:
>>
>>> Hi,
&g
actually, build fails IF merging). I have a feeling this might be
> needed if using LibreSSL, but I don't have an environment to test it.
>
> Thoughts and comments?
>
I haven't had a chance to grok the rest yet, but wanted to express support
for keeping some known SHA256 sums for convenience (perhaps in a separate
file, perhaps in the same file) and ask why a separate file shouldn't be
committed.
Cheers,
Nathan
On Wed, Oct 16, 2024 at 3:16 PM Nathan Hartman wrote:
>
> On Wed, Oct 16, 2024 at 10:45 AM wrote:
>>
>> Author: rinrab
>> Date: Wed Oct 16 14:45:20 2024
>> New Revision: 1921361
>>
>> URL: http://svn.apache.org/viewvc?rev=1921361&view=rev
&g
;
> /* Convert slashes to backslashes because the \\?\ path format
>
>
>
I didn't look at the code; replying to the commit message from mobile,
but...
Because Clang complained about taking the address of a RVALUE, I think it
was a typo in the code, rather than inability to use const.
I think this was intended:
(const WCHAR*)&buffer
but this was written:
&(const WCHAR*)buffer
and I wonder how MSVC didn't notice that.
Cheers,
Nathan
On Fri, Sep 27, 2024 at 3:26 PM Johan Corveleyn wrote:
>
> On Thu, Sep 26, 2024 at 5:34 PM Nathan Hartman
> wrote:
> >
> > On Thu, Sep 26, 2024 at 10:16 AM Daniel Sahlberg
> > wrote:
> > >
> > > Den tors 26 sep. 2024 kl 15:31 skrev Johan Corveley
until 1.15 release)
* 1.14.4 release announcement
* 1.14 release notes
If we don't get around to actually removing the BDB backend code
before 1.15, it could still exist in the tarballs but with additional
notes that it is "obsolete, not maintained, and no longer tested" in:
* 1.15 release notes
* configure warning if building with bdb in 1.15
10 years and lots of notice about deprecation sound like they "should
be enough for everyone" but tell that to everyone who still uses
Python 2. :-)
Cheers,
Nathan
On Sat, Jul 27, 2024 at 11:23 PM Nathan Hartman
wrote:
> On Sat, Jul 27, 2024 at 3:24 PM Daniel Sahlberg <
> daniel.l.sahlb...@gmail.com> wrote:
>
(snip)
>
>> [[[
>> Dear package maintainer,
>>
>> We have reason to believe you are maintaining the
On Sat, Jul 27, 2024 at 3:24 PM Daniel Sahlberg
wrote:
> Den tis 11 juni 2024 kl 04:29 skrev Nathan Hartman <
> hartman.nat...@gmail.com>:
>
>> [...] It would be nice to hear
>> from binary packagers. Will they overwhelmingly say "yes please! It's
>> a
site mobile friendly and implemented the hamburger menu.
I missed this email yesterday but I see that you already deleted them.
Thanks for cleaning up!
Cheers,
Nathan
On Wed, Jul 17, 2024 at 2:35 PM Timofei Zhakov wrote:
> On Wed, Jul 17, 2024 at 8:21 PM Nathan Hartman
> wrote:
> >
> > On Wed, Jul 17, 2024 at 10:31 AM Timofei Zhakov
> wrote:
> > (snipping most content)
> > > When I was was doing that, I solved the pr
ned address? I think we need some default string. Perhaps
"unknown"?
Cheers,
Nathan
ailer.py could be tested against
the 1.14.x branch to see if any additional fix(es) need to be included in
1.14.4.
Thanks,
Nathan
; --
> Jun Omae (大前 潤)
>
Missing ws2_32.lib errors: this patch depends on the earlier patch
"svn-fix-ws2_32.patch.txt"
which hasn't been committed yet. That patch can be found in [1]. I don't
have Windows setup right now so I can't test it, but if you can test it
then maybe you could go ahead and commit that one?
[1]
https://lists.apache.org/thread/gz3x1gn7r5r9ynrtp954pmfhsbgrgnm4
Cheers,
Nathan
On Mon, Jun 10, 2024 at 4:03 PM Daniel Sahlberg
wrote:
>
> Den sön 9 juni 2024 kl 03:00 skrev Nathan Hartman :
(snip)
>> Hi Timofei,
>>
>> I am really glad to see this being addressed!
>>
>> CMake has been requested here before (such as [1], [2], and [3])
Jenkins; we probably
should stick with buildbot unless there is a good reason to switch.
My opinion is to go ahead and remove the hudson stuff, because it has
been unmaintained for a significant time.
[1] https://infra.apache.org/build-supported-services.html#jenkins
Cheers,
Nathan
ces:
[1] Building SVN on Windows:
dev@ thread "Building SVN (dependencies) on Windows" started 20 Apr 2020
https://lists.apache.org/thread/qf1tfohrwjrjk4qm1j1l8z11hfthlcq3
Notably this response from Wireshark maintainer Graham Bloice:
https://lists.apache.org/thread/qdvl8hdb19fnq75qfx5wmxm5b1ylkdzd
[2] Building SVN for Synology NAS:
dev@ thread "SVN on Synology" started 17 Aug 2020
https://lists.apache.org/thread/q85nxhcfq574mxnnt8fdb2v1sxl09d32
Johan discusses CMake in this reply:
https://lists.apache.org/thread/32kydm0y6826h099xgk48prxn8vbq9p9
[3] Building SVN for Android with NDK:
dev@ thread "Cross compiling build instructions" started 15 Oct 2019
https://lists.apache.org/thread/qqll3l0kcon2k47q8qjyqr4htd9jmz2p
CMake discussed in this follow-up:
https://lists.apache.org/thread/djj5gns3d06t4k0m6mxs2s1zr8xkbgwo
Your efforts are very much appreciated.
Thanks, and cheers,
Nathan
On Thu, May 30, 2024 at 5:25 PM Nathan Hartman wrote:
>
> On Thu, May 30, 2024 at 5:09 PM Sands, Daniel N. via users
> wrote:
>>
>>
>> On 2024/02/15 17:42:59 "Sands, Daniel N. via users" wrote:
>> > On Thu, 2024-02-15 at 08:55 -0500, Nico Kadel-G
xes in the --change argument parser were committed in
> r1917944 and r1917864.
>
> Patch by: Timofey Zhakov (tima {at} chemodax _dot_ net)
> ]]]
>
> Thanks!
>
> --
> Timofei Zhakov
Committed in r1918181.
Thanks!
Nathan
On Mon, Jun 3, 2024 at 9:42 PM Nathan Hartman wrote:
>
> On Thu, May 30, 2024 at 2:05 PM Timofey Zhakov wrote:
> >
> > Hello,
> >
> > I found that the print_properties() creates an iterpool, but cleans it
> > inside the 'if' block instead of doi
gt; Fix unbounded memory usage in the `svn proplist --xml` command.
>
> * subversion/svn/proplist-cmd.c:
> (proplist_receiver_xml): Invoke the svn_pool_clear function
> on every iteration to clear the pool.
> ]]]
>
> --
> Timofei Zhakov
Committed in r1918139.
Thank you!
Nathan
]
>
> Thanks!
>
> --
> Timofei Zhakov
Committed in r1918138.
Thank you for noticing and fixing!
Cheers,
Nathan
On Thu, May 30, 2024 at 1:43 PM Timofey Zhakov wrote:
>
> Hi Nathan!
>
> Thank you for the review.
>
> I agree with your recommendations. Could you please commit the "v7" patch?
Committed in r1918076.
Thanks!
Nathan
On Sun, May 26, 2024 at 2:34 PM Timofey Zhakov wrote:
>
> On Wed, May 22, 2024 at 10:26 PM Timofey Zhakov wrote:
> >
> > Hi Nathan,
> >
> > On Wed, May 22, 2024 at 4:06 PM Nathan Hartman
> > wrote:
> > >
> > > On Tue, May 21, 2024 at 10:3
t_paths_for_diff_labels): Invoke svn_dirent_local_style() function
> when making BAD_RELATIVE_PATH error to create the error with correct paths.
> ]]]
>
> Thanks!
>
> --
> Timofei Zhakov
Committed in r1917946.
Nominated for backport to 1.14.x in r1917947.
Thanks again!
Nathan
gt; > * subversion\svn\svn.c
> > (sub_main): Add check of the changeno_end variable for zero.
> > * subversion\tests\cmdline\diff_tests.py
> > (diff_invalid_change_arg): Add test case for a diff of change,
> > done in revision range '1-0' and expect an error from it.
> >
> > Found by: jun66j5
> > ]]]
> >
> > Best regards.
>
> Oops, I found that the patch doesn't apply because of wrong encoding.
> Attaching a new one.
>
> --
> Timofei Zhakov
Committed in r1917944.
Nominated for backport to 1.14.x in r1917945.
Thanks!
Nathan
e fixes back to sub_main()
on a branch. It's an extra step but not difficult.
I'll try to look at the code in a little while. If you still have the
changes in your working copy, you can send a patch (even if
incomplete/draft) and I'll look at them together.
Thanks!
Nathan
On Mon, May 20, 2024 at 10:37 AM Timofey Zhakov wrote:
>
> On Mon, May 20, 2024 at 7:03 AM Nathan Hartman
> wrote:
> >
> > On Sun, May 19, 2024 at 4:09 PM Timofey Zhakov wrote:
> > >
> > > Hi,
> > >
> > > I found a little bug in par
sign is read by strtol(). That's several lines above
your change in svn.c (line 2379 on trunk@1917826). We are doing:
changeno_end = strtol(s, &end, 10);
but we are not checking if 'changeno_end' is negative (which it isn't
allowed to be).
I'm okay to commit this patch now and handle the second bug in a
follow-up, or handle both bugs together. Let me know what you prefer.
Cheers,
Nathan
has limited use, if you have questions please ask on the mailing
>> > list https://subversion.apache.org/mailing-lists#dev-ml
>> > ]]]
>>
>> Reads well. Fine with me!
>>
>
> Thank you, and also thanks to Nathan for reviewing the changes to the
> website.
>
>
e/staging/faq.ja.html [utf-8] (original)
> +++ subversion/site/staging/faq.ja.html [utf-8] Sun May 5 08:27:07 2024
> @@ -463,7 +463,6 @@ Win32システムには、シンボリ�
>Subversion ユーザーズメイリングリスト ( href="mailto:us...@subversion.apache.org";>us...@subversion.apache.org)
> — 注意: このメイリングリストは href="#moderation">モデレータ制だから、あなたの投稿が配送されるまでには、少し遅延があるかも。
>https://svn.haxx.se/users/";>Subversion ユーザーズリストのアーカイブ
> - IRC。irc.libera.chat の #svn チャンネルにて。
>
>
>
>
> Modified: subversion/site/staging/faq.zh.html
> URL:
> http://svn.apache.org/viewvc/subversion/site/staging/faq.zh.html?rev=1917512&r1=1917511&r2=1917512&view=diff
> ==
> --- subversion/site/staging/faq.zh.html [utf-8] (original)
> +++ subversion/site/staging/faq.zh.html [utf-8] Sun May 5 08:27:07 2024
> @@ -443,7 +443,6 @@ href="http://svn.collab.net/repos/svn/tr
> >us...@subversion.apache.org)
> — 注意这个列表需要经过审核，所以在显示之前有一些延迟。
>https://svn.haxx.se/users/";>Subversion用户信息列表。
> - 在线聊天系统（IRC）在irc.libera.chat的#svn频道。
>
>
>
>
>
Looks good to me! +1 to merge to publish whenever you're ready.
Thanks for taking care of this!
Cheers,
Nathan
n the name as already mentioned, but I agree that we should update
the channel topics to direct user questions to the mailing list where they
are much more likely to receive a timely response.
I'd also recommend to update our text on the website to say that the IRC
channels exist but the mailing lists are the more recommended way to
communicate.
Cheers,
Nathan
d in r1915316"
archived at:
https://lists.apache.org/thread/ds24b6w446horzvl4n8y6dqrfl3jb6s4
[2] 1 Feb 2024 mail to dev@ titled
"Re: svn commit: r1915317 - /subversion/branches/1.14.x/STATUS"
archived at:
https://lists.apache.org/thread/571hk0nykvrorx9wq0r0lyylpjj42qdw
Thanks,
Nathan
On Tue, Feb 20, 2024 at 3:25 PM Julian Foad wrote:
>
> 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'? [...]
is idea. If so, then after you commit the patch,
I'll be happy to make the branch, reverse-cherrypick it there, and write
the BRANCH-README.
If you don't think it's worth saving, even in a branch, that's okay too.
Cheers,
Nathan
stract like PoD in a visual way.
Do we have any artists among us who would like to put something
together? Please speak up, and I'll help by coordinating with the
organizers.
Cheers,
Nathan
mpared to the salted SHA-1?
> - Should we even do both?
>
> Any other points?
>
> Any thoughts?
>
> I would like to see this thread progress and I hope we can find consensus on
> a way forward.
>
> Kind regards,
> Daniel Sahlberg
I, too, hope the community can come together and reach a consensus,
whatever that ends up being.
[1]
https://www.securityweek.com/nist-retire-27-year-old-sha-1-cryptographic-algorithm/
Cheers,
Nathan
n occurs with large
>> repositories.
>> + Votes:
>> + +1: jun66j5
>> +
>> Veto-blocked changes:
>> =
>>
>
> Is this serious enough that we should consider a 1.14.4 release? (Didn't
> have time to review the code yet but a quick glance positive).
>
> Kind regards,
> Daniel
>
I was considering asking the same thing: It might be best to do a 1.14.4
release to fix the regression.
Nathan
/svn.apache.org/repos/asf/subversion/branches/1.14.x/subversion/bindings/swig/python/libsvn_swig_py
> |\
> + python3 -c "import re,sys;[print(re.sub(r'^(---|\+\+\+|Index:) ', r'\1
> ./subversion/bindings/swig/python/libsvn_swig_py/',l),end='') for l in
> sys.stdin]"
> +
> +
> +
> +
>
> Ruby bindings require swig 3.0.9
> ]]]
Are the revision numbers correct above? (It says fixed in r1915316 but 'svn
diff' command uses r1915338.)
Hope this helps,
Nathan
On Sat, Jan 13, 2024 at 3:56 PM Nathan Hartman
wrote:
> Pros: Future-proofing against the real and perceived brokenness of any
> hash types.
>
I meant to write:
Pros: Future-proofing against the real and perceived brokenness of any hash
types, or the deprecation and later removal
any future hashes that become
declared broken, requiring almost no additional work on our part. Notably,
it will not be necessary to bump the WC or protocol formats because of
hashes.
Pros: Future-proofing against the real and perceived brokenness of any hash
types.
Cons: Requires a lot of work up front, which no one might volunteer to do.
We should continue hashing out (pun intended) how to address the different
concerns raised.
Are there any technical reasons *not* to support other hashes going forward?
Are there other pros or cons to supporting a scenario like I described?
Thanks,
Nathan
On Fri, Dec 29, 2023 at 3:14 PM Nathan Hartman wrote:
>
> On Thu, Dec 28, 2023 at 11:01 PM wrote:
>>
>> Author: hartmannathan
>> Date: Fri Dec 29 04:01:21 2023
>> New Revision: 1914968
>>
>> URL: http://svn.apache.org/viewvc?rev=1914968&view=rev
>
begins:
At this point, the release may be publicly available, but its still a
> good
> idea to hold off on announcing it until after the mirrors have picked it
> up.
and continues expounding upon the mirrors and the 24 hour waiting period.
Just noticed it while re-reading this section on my phone. I'll make a note
to fix it when I reach a computer.
Doh!
Nathan
On Thu, Dec 28, 2023 at 2:51 PM Daniel Sahlberg
wrote:
(snip)
> Congratulations Nathan for your first Subversion release and a big Thank You
> for the effort!
>
> Kind regards,
> Daniel
Thanks! Well, it's not 100% done yet. I still need to update the
website and send the
holiday season to test
this release, and for your encouragement and support throughout this
process!
I'll proceed with the next steps shortly...
Cheers,
Nathan
References:
[1] https://lists.apache.org/thread/1j77sxsjfo4570ho08j104cddhq1pxhw
[2] https://lists.apache.org/t
On Sat, Dec 9, 2023 at 10:50 AM Nathan Hartman wrote:
>
> The 1.14.3 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thanks!
I'll go ahead
On Sat, Dec 9, 2023 at 10:50 AM Nathan Hartman wrote:
>
> The 1.14.3 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there.
>
> Thanks!
Hi all,
Just
The 1.14.3 release artifacts are now available for testing/signing.
Please get the tarballs from
https://dist.apache.org/repos/dist/dev/subversion
and add your signatures there.
Thanks!
Hi all,
Just a heads up, I plan to roll tarballs this week.
Hopefully all goes well and we'll be able to make the release soon...
Cheers,
Nathan
uestions:
Do we notify translators before a patch release? (i.e., should I send
out an email as described in #notify-translators [3]?)
I need to guesstimate the release date. If I can get to the point of
rolling tarballs within the next few days, how much time will be needed
by those who plan t
t a nomination/vote to a A.B.x branch, and sometimes done
via a vote... So I went ahead and took the most conservative approach,
but if it's overkill, please let me know for the future.
Thanks,
Nathan
On Wed, Nov 29, 2023 at 8:40 AM Daniel Sahlberg
wrote:
>
> Den ons 29 nov. 2023 kl 06:55 skrev Daniel Sahlberg
> :
>>
>>
>> ons 29 nov. 2023 kl. 05:57 skrev Nathan Hartman :
>>>
>>> The backport bot (svn-role) normally runs nightly but the most rec
yntax error in STATUS.
I don't have access to svn-qavm1 so I can't check why it didn't happen
automatically. Maybe someone with access could check if the machine is
at least running...
Thanks,
Nathan
ollowing):
[[[
#!/bin/sh
echo $PATH
echo $0
]]]
Try running it from the shell, then try running it through SVN with
'svn diff' with '--diff-cmd'. Does it print different values?
Thanks,
Nathan
tarts with "#!/bin/sh", then
> "svn diff --diff-cmd mydiff" works fine.
>
> Note about the use of "/usr/bin/env": with the actual script, this is
> actually "#!/usr/bin/env zsh" with the goal of using the same script
> on various platforms (where zsh can be at various places).
>
> --
> Vincent Lefèvre - Web: <https://www.vinc17.net/>
> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Thanks,
Nathan
On Sun, Nov 12, 2023 at 1:14 PM Daniel Sahlberg
wrote:
>
>
> sön 12 nov. 2023 kl. 19:02 skrev Nathan Hartman >:
>
>> In my adventures with tools/dev/unix-build/Makefile.svn, I saw two places
>> that call '-which', that is, 'which' preceded by
not familiar with this. What does '-which' do, and how is it different
from 'which'?
Thanks,
Nathan
On Fri, Nov 10, 2023 at 9:16 AM Daniel Sahlberg
wrote:
>
> Den fre 10 nov. 2023 kl 15:09 skrev Nathan Hartman :
>>
>> On Fri, Nov 10, 2023 at 8:02 AM Johan Corveleyn wrote:
>>>
>>> Hi Nathan,
>>>
>>> Sorry I haven't helped so far ... I s
On Fri, Nov 10, 2023 at 8:02 AM Johan Corveleyn wrote:
> Hi Nathan,
>
> Sorry I haven't helped so far ... I should be able to say something
> useful here, since I'm a java dev in my dayjob. But I have been
> drowning a bit in that same dayjob lately, so I can barely find
On Fri, Nov 3, 2023 at 12:00 AM Nathan Hartman wrote:
> Previously I mentioned I plan to RM for the upcoming 1.14.3 release.
> This being my first time, I need to solve some issues first.
>
> One of these, which has been a stumbling block for me since the
> beginning, is get
On Mon, Oct 16, 2023 at 9:16 AM Daniel Sahlberg
wrote:
>
> Den sön 15 okt. 2023 kl 06:50 skrev Nathan Hartman :
>>
>> On Fri, Oct 13, 2023 at 1:58 PM Johan Corveleyn wrote:
>>>
>>> On Fri, Oct 13, 2023 at 5:35 PM Stefan Sperling wrote:
>>> >
On Tue, Oct 17, 2023 at 8:15 AM Daniel Sahlberg
wrote:
> Den tis 17 okt. 2023 kl 14:06 skrev Nathan Hartman <
> hartman.nat...@gmail.com>:
>
>> On Tue, Oct 17, 2023 at 2:50 AM wrote:
>>
>>> Author: dsahlberg
>>> Date: Tue Oct 17 06:50:02 202
On Tue, Oct 17, 2023 at 2:50 AM wrote:
> Author: dsahlberg
> Date: Tue Oct 17 06:50:02 2023
> New Revision: 1913041
>
> URL: http://svn.apache.org/viewvc?rev=1913041&view=rev
> Log:
> In site/staging:
>
> WANdisco is renaming itself to Cirata. Update links accordingly.
>
> * packages.html
> (mu
Before I do, I need to get my system bootstrapped properly. I can build SVN
and run most of the testsuite, but one pesky longstanding issue I have had
is with the JavaHL bindings. That will require a separate thread and I'll
describe the issues there. I'll check my notes to see what else might be a
showstopper on my end.
If I can get set up and solve the problems I've encountered previously in a
reasonable time frame (and everyone's help is appreciated of course) I'll
volunteer.
Cheers,
Nathan
one of the
things I experimented with in my earlier attempts, but I may have
overlooked something because the test was still failing for me.
I'm away from my computer at the moment but I can follow-up with a few
examples elsewhere in the test suite. (You can also find them pretty easily
by grepping for expected_error and looking for messages that contain wc
paths.)
Cheers,
Nathan
On Sun, Oct 8, 2023 at 3:14 PM Daniel Sahlberg
wrote:
> I was able to reproduce the issue and thanks to Yasuhito's hints I was also
> able to fix it by using absolute paths when running the svn command. I've
> committed r1912826 with a simple fix which seems to work for me.
On Fri, Oct 6, 2023 at 10:50 AM Daniel Sahlberg
wrote:
>
> Den fre 6 okt. 2023 kl 06:26 skrev Nathan Hartman :
(snip)
>> This is on trunk, as of r1912743 (the latest right now), Linux Debian,
>> Python 3.7.5, building SVN with --enable-maintainer-mode (this might
>> accoun
On Thu, Oct 5, 2023 at 8:24 AM Daniel Sahlberg
wrote:
>
> Den tors 5 okt. 2023 kl 14:18 skrev Nathan Hartman :
>> I am considering nominating this for backport to 1.14.x. (At least, I don't
>> see a reason not to, since Python2 remains supported.)
(snip)
> Why not
ried changing '%s' to '.*%s'; also I
tried removing os.path.abspath when constructing from_path and
to_path; I made various other attempts, all aimed at minimally
matching the known portion of the path while ignoring the extra stuff.
Unfortunately I was not successful.
This is on
1 - 100 of 721 matches
Mail list logo
