c-libs` field.
>
> Affected only Windows.
> ]]]
>
> Thanks!
Committed myself in r1918596.
--
Timofei Zhakov
t;>
>> +option(SVN_BUILD_SVNXX "Enable compilation of the C++ bindings (requires
>> C++)" OFF)
>> +
>> # Setup modules path
>>
>> list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/build/cmake")
>
>
> Should be mentioned in the log message, I think.
>
> Kind regards,
> Daniel
>
Hello,
Thanks for the notice!
I was experimenting with SVNXX and forgot to revert this change :)
Reverted in revision 1918977.
--
Timofei Zhakov
completed are:
1. Swig and JavaHL bindings.
2. Documentation to INSTALL and maybe add a page to the website.
Any help on these items will be much appreciated.
Finally, I am thinking about merging the branch into 'trunk' and
continuing development and testing there. What do you think?
hout the 'lib' prefix in static
configuration.
2. Path separator (SVN_PATH_LOCAL_SEPARATOR) is not currently
configured correctly, so there might be some runtime problems when
converting the path from local style and to local style.
By the way, I think that Linux support of the CMake is not very
important due to the great and useful current build system which is
quite useful. I think it should work, but the basic target should be
Windows or unusual platforms that autoconf doesn't have a great
support for. However, as it is requested, I will try to improve
support for non-Windows platforms as well...
--
Timofei Zhakov
Hi,
On Tue, Jul 16, 2024 at 8:34 PM Daniel Sahlberg
wrote:
>
> Hi!
>
> Very good work, I've been looking at the commits as they've come in and I
> think it looks very promising.
Thank you!
> Den sön 14 juli 2024 kl 21:48 skrev Timofei Zhakov :
>>
>>
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 problem with uname with a
> > little patch by adding ifdef over release_name_from_unam
because the targets.cmake file didn't regenerate. Did you run
`./gen-make.py -t cmake`?
Thanks.
--
Timofei Zhakov
is that we will only need to support a single
build system across all possible platforms. This means we will only
have to implement features and utilities, such as dependency
searching, once, while ensuring cross-platform support. For example,
this approach could prevent scenarios where a feature is implemented
for Linux, but then requires fixes for the Windows build system.
Additionally, nowadays CMake is considered more modern than autoconf,
offering numerous advanced features for developers, packagers, and
users. It could sometimes work faster and be more configurable than
autoconf. However, this is just my personal opinion, and some
individuals may still prefer autoconf instead, so...
What do you think?
Thanks!
--
Timofei Zhakov
s used for build, and sometimes they
might be unstable. The resolution that Daniel suggested seems to be
nice, since we're migrating from configs. Additionally, if so, there
could be a similar problem with LZ4, when SVN_USE_INTERNAL_LZ4 is
disabled. If there is, we should also do something similar for
external LZ4.
Hope this explains well, because it is so complicated :)
[1] https://cmake.org/cmake/help/latest/command/find_package.html
--
Timofei Zhakov
der_wrappers.py .\build.conf swig
Otherwise, there will be a failure due to missing include files. In
the feature these commands will be executed from somewhere else
automatically. Also don't forget to enable the SVN_ENABLE_SWIG_PYTHON
option.
Thanks!
--
Timofei Zhakov
On Sat, Aug 10, 2024 at 10:26 PM Daniel Sahlberg
wrote:
>
> Den tors 8 aug. 2024 kl 23:42 skrev Timofei Zhakov :
>>
>> On Thu, Aug 8, 2024 at 9:44 PM wrote:
>> >
>> > Author: rinrab
>> > Date: Thu Aug 8 18:44:01 2024
>> > New Revision: 1
RGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DVERSION=\"\"
-DXS_VERSION=\"\" -DLINUX -D_REENTRANT -D_GNU_SOURCE
]]]
I think setting of the most of these options will resolve the issue
and make the build with CMake more similar to other build systems.
However, by excluding some options and testing, I noticed that setting
only of the _GNU_SOURCE definition also worked.
--
Timofei Zhakov
On Sun, Aug 11, 2024 at 3:17 PM Daniel Sahlberg
wrote:
>
> Den sön 11 aug. 2024 kl 11:38 skrev Timofei Zhakov :
>>
>>
>> I think setting of the most of these options will resolve the issue
>> and make the build with CMake more similar to other build systems.
>>
sically the suggested code looks nice, but I would like to add an
'else' block to message 'NONE' instead of an empty version if ra-serf
is disabled.
[[[
if(SVN_ENABLE_RA_SERF)
message(STATUS "SERF .......... : ${Serf_VERSION}")
else()
message(STATUS "SERF .. : NONE")
endif()
]]]
Additionally, the versions of Gettext, Intl, Python, Perl, Ruby (not
yet implemented but will be soon) currently are not listed there, but
should be. Most of these dependencies could be disabled via options as
well.
--
Timofei Zhakov
or packagers use the amalgamation. However the amalgamation is simpler
to use on WIndows than the installed one, because it doesn't require
any compilation, so the other users could use it and it might be
better to check both versions in this case for sure.
--
Timofei Zhakov
On Mon, Aug 12, 2024 at 10:47 PM Daniel Sahlberg
wrote:
>
> Den mån 12 aug. 2024 kl 16:30 skrev Timofei Zhakov :
>>
>> I agree the version should not be listed when we don't have this
>> dependency. Based on Daniel's suggestions, I think that the behaviour
>
On Tue, Aug 13, 2024 at 5:52 AM Jun Omae wrote:
>
> On 2024/08/09 6:41, Timofei Zhakov wrote:
> > On Thu, Aug 8, 2024 at 9:44 PM wrote:
> >>
> >> Author: rinrab
> >> Date: Thu Aug 8 18:44:01 2024
> >> New Revision: 1919757
> >>
&g
On Tue, Aug 13, 2024 at 10:34 PM Timofei Zhakov wrote:
>
> On Tue, Aug 13, 2024 at 5:52 AM Jun Omae wrote:
> >
> > On 2024/08/09 6:41, Timofei Zhakov wrote:
> > > On Thu, Aug 8, 2024 at 9:44 PM wrote:
> > >>
> > >> Author: rinrab
> &
On Sat, Aug 17, 2024 at 6:22 PM Daniel Sahlberg
wrote:
>
> Den mån 12 aug. 2024 kl 23:12 skrev Timofei Zhakov :
>>
>> On Mon, Aug 12, 2024 at 11:39 PM Daniel Sahlberg
>> wrote:
>> >
>> > Hi,
>> >
>> > One question on the SQLiteAma
declaration of 'err'
shadows a previous local [-Wshadow]
2587 | svn_error_t *err =
svn_cstring_atoi(&opt_state.limit, utf8_opt_arg);
| ^~~
subversion/svnlook/svnlook.c:2471:16: note: shadowed declaration is here
2471 | svn_error_t *err;
|^~~
subversion/svnlook/svnlook.c:2587:13: error: ISO C90 forbids mixed
declarations and code [-Werror=declaration-after-statement]
2587 | svn_error_t *err =
svn_cstring_atoi(&opt_state.limit, utf8_opt_arg);
| ^~~
]]]
--
Timofei Zhakov
d into the trunk.
My next goal is to setup continuous integration using GitHub Actions
for the CMake build to see how it works with different platforms and
configurations.
--
Timofei Zhakov
Merged in revision 1920717!
On Sat, Sep 14, 2024 at 3:17 PM Daniel Sahlberg
wrote:
>
> Den lör 14 sep. 2024 kl 14:46 skrev Timofei Zhakov :
>>
>> Hi,
>>
>> I've made some progress with the CMake build:
>>
>> 1. It now works perfectly across diffe
On Sun, Sep 22, 2024 at 2:02 AM Jun Omae wrote:
>
> On 2024/09/21 5:50, Timofei Zhakov wrote:
> > On Fri, Sep 20, 2024 at 11:30 AM Jun Omae wrote:
> >>
> >> Hi,
> >>
> >> On 2024/09/16 21:41, rin...@apache.org wrote:
> >>> Author: ri
> "${CMAKE_CURRENT_SOURCE_DIR}/build/run_tests.py"
> +--bin ${CMAKE_CURRENT_BINARY_DIR}
> +--tools-bin ${CMAKE_CURRENT_BINARY_DIR}
> +--verbose
> +--log-to-stdout
> +--set-log-level=WARNING
> +${CMAKE_CURRENT_SOURCE_DIR}
> +${CMAKE_CURRENT_BINARY_DIR}
> +${py_test_path}
> +)
>endforeach()
> endif()
>
> ]]]
Thanks for reviewing and noticing this!
Changing the glob pattern seems to be a great resolution to me. Are
you going to commit it?
--
Timofei Zhakov
ke, so simply adding configuration of this script is
complicated, because it should be configured into build dir.
[1] https://svn.apache.org/viewvc?view=revision&revision=r1887324
What do you think?
--
Timofei Zh
On Mon, Sep 23, 2024 at 9:25 AM Jun Omae wrote:
>
> On 2024/09/22 22:55, Timofei Zhakov wrote:
> > On Sun, Sep 22, 2024 at 2:02 AM Jun Omae wrote:
> >>
> >> On 2024/09/21 5:50, Timofei Zhakov wrote:
> >>> On Fri, Sep 20, 2024 at 11:30 AM Jun Omae wrot
On Mon, Sep 23, 2024 at 6:17 AM Jun Omae wrote:
>
> On 2024/09/22 23:24, Timofei Zhakov wrote:
> > On Sun, Sep 22, 2024 at 2:12 AM Jun Omae wrote:
> >>
> >> On 2024/09/18 21:12, rin...@apache.org wrote:
> >>> Author: rinrab
> >>> Date
On Wed, Sep 25, 2024 at 6:22 PM Timofei Zhakov wrote:
>
> On Wed, Sep 25, 2024 at 2:29 PM Jun Omae wrote:
> >
> > On 2024/09/22 23:34, Timofei Zhakov wrote:
> > > Hi,
> > >
> > > I am currently working on testing with CMake.
> > >
&g
esolving the
issue, because I think there is no generator expression to get the
target dir in the current config without a specific target. However, I
think it's better to use svn's target dir since it's the main
executable and maybe the same for tools (?). It actually should be the
same for all targets, so it doesn't meter.
Also, I think we should add some multi-config generator tests to the
GitHub Actions workflow, to prevent similar problems in future.
--
Timofei Zhakov
uby/libsvn_swig_ruby/swigutil_rb.h:svn_swig_rb_conflict_resolver_func
> ]]]
Thank you for making this list. Will commit the reformatting soon.
--
Timofei Zhakov
On Fri, Sep 6, 2024 at 1:41 PM Timofei Zhakov wrote:
>
> Hi,
>
> I am currently thinking about setting up GitHub Actions in Subversion.
>
> GitHub Actions will help us test every commit in different
> configurations, which, based on my experience, is very useful. It'
tting msvc_force_static from msvc-force-static) and
> build/generator/gen_[cmake|win].py (using msvc_force_static).
Yes, there are no more usages of this option. I have already made a
patch where it is removed, but decided to wait a bit and commit it
later.
--
Timofei Zhakov
On Thu, Sep 19, 2024 at 3:05 PM Timofei Zhakov wrote:
>
> On Thu, Sep 19, 2024 at 2:59 PM Daniel Sahlberg
> wrote:
> >
> > Den ons 18 sep. 2024 kl 18:38 skrev :
> >>
> >> Author: rinrab
> >> Date: Wed Sep 18 16:38:36 2024
> >> New Revision
On Wed, Sep 25, 2024 at 2:29 PM Jun Omae wrote:
>
> On 2024/09/22 23:34, Timofei Zhakov wrote:
> > Hi,
> >
> > I am currently working on testing with CMake.
> >
> > I've noticed that there are some test scripts that implement custom
> > SVN_E
On Wed, Sep 25, 2024 at 11:58 AM Jun Omae wrote:
>
> On 2024/09/24 7:07, Timofei Zhakov wrote:
> > On Mon, Sep 23, 2024 at 9:25 AM Jun Omae wrote:
> >>
> >> On 2024/09/22 22:55, Timofei Zhakov wrote:
> >>> On Sun, Sep 22, 2024 at 2:02 AM Jun Omae wrote:
; funcs ${contents})
>
>foreach(func_string ${funcs})
> -string(REGEX REPLACE "${func_regex}.*$" "\\2" func_name
> ${func_string})
> -
> +string(REGEX MATCH "[A-Za-z0-9_]+[ \t\r\n]*\\($" func_name
> ${func_string})
> +string(REGEX REPLACE "[ \t\r\n]*\\($" "" func_name ${func_name})
> list(APPEND defs "${func_name}")
>endforeach()
>
> ]]]
>
> Thoughts?
This patch seems to be working and it resolves the issue. I think it's
okay to commit it. Would you like to do it, or should I commit it?
--
Timofei Zhakov
On Tue, Sep 17, 2024 at 7:55 PM Timofei Zhakov wrote:
>
> Hi,
>
> On Tue, Sep 17, 2024 at 6:45 AM Jun Omae wrote:
> >
> > On 2024/09/16 21:41, rin...@apache.org wrote:
> > > Author: rinrab
> > > Date: Mon Sep 16 12:41:13 2024
> > > New Revis
:)
> 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.
> ]]]
Done. Explained it a bit more.
> Congrats on finding that!
Thanks!
--
Timofei Zhakov
On Sat, Nov 23, 2024 at 10:39 PM Timofei Zhakov wrote:
>
> [...]
>
> > However, there are some technical limitations in the current merge
> > implementation, which prohibit it to be used outside of the merge
> > command, but the merge implementation can be split on
/svn.apache.org/repos/asf/subversion/branches/apply-processor>.
I am going to move some code from merge.c to merge_processor.c, and then
resolve the issues and fix the tests.
--
Timofei Zhakov
ditor.sh')
+ svneditor_script = os.path.join(sys.path[0], 'svneditor.sh')
# Username and password used by the working copies
wc_author = 'jrandom'
]]]
What do you think? Did it work for you?
--
Timofei Zhakov
re already named as `bpatch` somewhere
and 2) it didn't sound pretty good for me. Then, I finally had a look
on `xpatch`, due to XML format. Generally, it looks nice for me and I decided
to keep it simple, without going deeply into naming, in order to save time.
I am happy to hear any other voice about the name of the feature. This is an
important part of it and this decision has to be done and accepted by the
whole community.
--
Timofei Zhakov
t
will wait with the most major part, where the merge_processor.c file
has been factored out from merge.c, so we will ensure that the
functionalities have not been changed.
[1]:
https://svn.apache.org/repos/asf/subversion/branches/apply-processor@1922202
--
Timofei Zhakov
by asfgit).
> >
> > Head commit for run:
> > ae29c4b73af9d80276ab90a0c9d675e241335b90 / Timofei Zhakov
> >
> > Minor code format in merge.c.
> >
> > * subversion/libsvn_client/merge.c
> > (record_tree_conflict): Fix indentation of the variables' declarations.
> >
>
On Mon, Dec 2, 2024 at 7:04 PM Nathan Hartman wrote:
>
> 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:
> > >
On Tue, Nov 26, 2024 at 4:25 AM Jun Omae wrote:
>
> On 2024/11/25 21:00, Timofei Zhakov wrote:
> > Hi Daniel!
> >
> > I am happy to see your feedback.
> >
> > On Sun, Nov 24, 2024 at 6:17 PM Daniel Shahaf
> > wrote:
> >>
> >> rin...@
en tests are beginning
to run, like when `make check` has been invoked.
So, if a few tests are running at the same time, they will try to create
one working-copy over another, causing a failure.
To try it out, run the tests using `ctest -j 16` command (it will fail).
--
Timofei Zhakov
On Mon, Nov 25, 2024 at 1:00 PM Timofei Zhakov wrote:
>
> Hi Daniel!
>
> I am happy to see your feedback.
>
> On Sun, Nov 24, 2024 at 6:17 PM Daniel Shahaf wrote:
> >
> > rin...@apache.org wrote on Thu, 26 Sep 2024 13:22 +00:00:
> > > Fix command-line test
Timofei Zhakov
On Sun, 29 Dec 2024 at 4:00 PM, Daniel Sahlberg
wrote:
> Den tis 24 dec. 2024 kl 18:26 skrev Timofei Zhakov :
>
>>
>> Hi Daniel,
>>
>> Thanks for this feedback, but probably you didn't fully get this commit.
>> This is a fix to a stu
Nathan Hartman <
> hartman.nat...@gmail.com>:
>
>> On Tue, Nov 26, 2024 at 12:23 PM Timofei Zhakov
>> wrote:
>> >
>> > On Sun, Nov 24, 2024 at 5:25 PM Daniel Shahaf
>> wrote:
>> > > Don't leak implementation details into
gt;
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
>
>
Hi,
I think that it might be a good idea to commit the `Enable GitHub Actions
workflows in pull requests` [1] commit from this PR into the trunk.
What do you think?
[1]:
https://github.com
cause it's a bit incorrect to add such an
argument to the svn_client API. It's svn-exe's responsibility, to handle
this switch, over the format detected automatically. Let's not
overcomplicate our life!
--
Timofei Zhakov
On Fri, Dec 13, 2024 at 11: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' text
about the stuff that we
need to finish before getting the trunk out. Do we have such?
I'll do this revision for the CMake builds system support soon. There
are some unfinished functionalities and the features that I want to
have in 1.15.0.
Thanks!
--
Timofei Zhakov
On Fri, Dec 13, 2024 at 4:07 PM Timofei Zhakov wrote:
>
> > However, I noticed a little problem in the implementation of patching; The
> > svn_client_patch() function accesses the patchfile by an absolute path
> > instead of a handle to a file. This follows that the file wil
ch to the email as 'svn-patch-by-file-wip-v1.patch.txt'.
What do you think, should I continue this work?
PS: this is a patch of svn-patch :-)
--
Timofei Zhakov
Index: subversion/include/svn_client.h
===
--- sub
and they want to reject all other formats.
>
> Now, unidiff can start with a log message, but can xpatch do that? I
> think the xml processing instruction must be first in the file. So,
> perhaps the log can be provided with some sort of tags within the xml
> structure? Maybe we p
On Fri, Dec 13, 2024 at 6:02 PM Timofei Zhakov wrote:
>
> On Fri, Dec 13, 2024 at 4:07 PM Timofei Zhakov wrote:
> >
> > > However, I noticed a little problem in the implementation of patching; The
> > > svn_client_patch() function accesses the patchfile by an ab
On Sat, Nov 23, 2024 at 12:01 AM Timofei Zhakov wrote:
> On Fri, Nov 22, 2024 at 4:07 PM wrote:
>
>> Author: hartmannathan
>> Date: Fri Nov 22 15:07:32 2024
>> New Revision: 1922026
>>
>> URL: http://svn.apache.org/viewvc?rev=1922026&view=rev
&g
t; run: |
>C:\vcpkg\vcpkg.exe install --triplet ${{ matrix.vcpkg_triplet
> }} `
> @@ -120,7 +120,7 @@ jobs:
>
>
> "CMAKE_TOOLCHAIN_FILE=C:/vcpkg/scripts/buildsystems/vcpkg.cmake" >>
> $env:GITHUB_ENV
>
> - - name: Install dependecies (Linux, apt-get)
> + - name: Install dependencies (Linux, apt-get)
> if: runner.os == 'Linux'
> run: >
>sudo apt-get update &&
>
>
>
My favorite words to misspell with :~)
--
Timofei Zhakov
ture.
4. Implement writer and parser for xpatch files in the branch.
5. Add`svn diff -–xpatch` and `svn merge -–xpatch` commands by
connecting diff driver, xpatch file routines, and "apply"
tree-processor together in the same branch.
I have a working prototype of xpatch file writer and parser, but it
seems to be far from ready.
--
Timofei Zhakov
ignore_content_type,
ignore_properties,
properties_only,
- FALSE /*use_git_diff_format*/,
+ use_git_diff_format,
pretty_print_mergeinfo,
argument whether
it's a local abspath or not. This may cause a crash later on.
Am I right with this or is there conceptual proof behind?
[1]
https://github.com/apache/subversion/blob/54e2d898f180c47050d0fc788f75ab5e2e43f6e1/subversion/libsvn_client/info.c#L353
--
Timofei Zhakov
Hi again,
I made several patches which will fix the issue.
svn-info-assert-path.patch.txt and svn-info-fix-revision-kind.patch.txt
files are attached to this email.
Any thoughts?
On Fri, May 2, 2025 at 4:20 PM Timofei Zhakov wrote:
> Hi,
>
> I was consuming the Subversion API, e
hes() before your change.
>
It should not be leaked because it will be free'd on pool cleanup and even
the file will be closed. As far as I can tell Subversion relies on this
behaviour quite frequently.
--
Timofei Zhakov
verify one group each, so we can combine them. But I didn't initially like
it, and IMO it's fine to duplicate those checks.
Any thoughts? If it seems nice to everyone, I'll commit it.
On Fri, May 9, 2025 at 4:29 PM Timofei Zhakov wrote:
> [...]
>
>> *This* is clearly wr
oing something complicated. There's no
> reason to not have both svn_client_patch() and svn_client_patch2() in the
> non-deprecated API.
>
>
> Although in that case it could be svn_client_patch_stream() or something
> like that. And could use our stream API, if that makes any kind of sense.
>
> -- Brane
>
--
Timofei Zhakov
vn_test_opts_t *opts,
>const char *reject_tempfile_path;
>const char *key;
>int i;
> + apr_off_t off;
> +
> #define NL APR_EOL_STR
> #define UNIDIFF_LINES 7
>const char *unidiff_patch[UNIDIFF_LINES] = {
> @@ -401,8 +403,8 @@ test_patch(const svn_test_opts_t *opts,
>pool, svn_test_data_path("test-patch", pool),
>"test-patch.diff", SVN_VA_NULL);
>SVN_ERR(svn_io_file_open(&patch_file, patch_file_path,
> - (APR_READ | APR_WRITE | APR_CREATE |
> APR_TRUNCATE),
> - APR_OS_DEFAULT, pool));
> + (APR_READ | APR_WRITE | APR_CREATE |
> APR_TRUNCATE
> +| APR_BUFFERED), APR_OS_DEFAULT, pool));
>for (i = 0; i < UNIDIFF_LINES; i++)
> {
>apr_size_t len = strlen(unidiff_patch[i]);
> @@ -415,9 +417,12 @@ test_patch(const svn_test_opts_t *opts,
>pcb.patched_tempfiles = apr_hash_make(pool);
>pcb.reject_tempfiles = apr_hash_make(pool);
>pcb.state_pool = pool;
> - SVN_ERR(svn_client_patch(patch_file_path, wc_path, FALSE, 0, FALSE,
> - FALSE, FALSE, patch_collection_func, &pcb,
> - ctx, pool));
> +
> + off = 0;
> + SVN_ERR(svn_io_file_seek(patch_file, APR_SET, &off, pool));
> + SVN_ERR(svn_client_patch2(patch_file, wc_path, FALSE, 0, FALSE,
> +FALSE, FALSE, patch_collection_func, &pcb,
> +ctx, pool));
>SVN_ERR(svn_io_file_close(patch_file, pool));
>
>SVN_TEST_ASSERT(apr_hash_count(pcb.patched_tempfiles) == 1);
>
>
>
--
Timofei Zhakov
ith file api.
However, nothing really complicated is needed. This also will make the
patch implementation more straightforward, due to the stream abstraction.
In other words, this will be helpful, and if you wish to try it out -- I'm
fully +1 for this. I'll be happy to see and review it as needed!
> -- Brane
>
--
Timofei Zhakov
I understand, this is currently used for ezt
python generator (which is actually made by gstein), lz4, utf8proc, but I
think these libraries can also be installed on the system.
Thoughts?
PS: maybe it makes sense to add a possibility to run the whole test suite
in venv? I'm actually aware of how it works, sorry if I'm wrong...
--
Timofei Zhakov
>
> PS: maybe it makes sense to add a possibility to run the whole test suite
> in venv? I'm actually *aware *of how it works, sorry if I'm wrong...
>
sp. aware -> *un*aware
--
Timofei Zhakov
On Sun, May 18, 2025 at 9:48 PM Branko Čibej wrote:
> On 23. 11. 24 11:26, Timofei Zhakov wrote:
>
> Hi!
>
> I am using patches frequently, however, 'svn diff' and 'svn patch'
> commands currently have several limitations:
>
> 1. They do not track tree
>
>
> Sure you can run the whole test suite like that, that's basically what my
> changes are doing.
>
>
It seems like the tests actually started failing on windows after r1925717
in the trunk. See logs on github actions:
https://github.com/apache/subversion/actions/runs/1
Would this be helpful?
(see the patch in the attachments)
--
Timofei Zhakov
Index: build/run_tests.py
===
--- build/run_tests.py (revision 1925818)
+++ build/run_tests.py (working copy)
@@ -315,6 +315,8 @@
cmdline.append
On Mon, May 26, 2025 at 8:54 PM Branko Čibej wrote:
> On 26. 5. 25 15:40, Timofei Zhakov wrote:
>
> Would this be helpful?
>
> (see the patch in the attachments)
>
>
>
> This just throws out all the dependency setup and special-cases schema
> verification,
On Mon, May 26, 2025 at 8:29 PM Branko Čibej wrote:
> On 26. 5. 25 14:07, Timofei Zhakov wrote:
>
> On Tue, May 20, 2025 at 9:29 PM Branko Čibej wrote:
>
>> On 20. 5. 25 20:31, rin...@apache.org wrote:
>>
>> Author: rinrab
>> Date: Tue May 20 18:31:35 202
On Mon, May 26, 2025 at 10:07 PM Branko Čibej wrote:
> On 26. 5. 25 21:25, Timofei Zhakov wrote:
>
> On Mon, May 26, 2025 at 8:29 PM Branko Čibej wrote:
>
>> On 26. 5. 25 14:07, Timofei Zhakov wrote:
>>
>> On Tue, May 20, 2025 at 9:29 PM Branko Čibej wrote:
can be
executed with non-utf8-ized arguments. In wmain() apr_conv_ucs2_to_utf8()
just ignores the error, which is bad (on win32).
And finally, the code we have right now is pretty good, and it seems
possible to support non-ASCII arguments (which I'm working on).
I hope this makes some sense.
--
Timofei Zhakov
__get_utf8_argv(), which may cause issues. Actually
no, but it's still better to copy it for sure.
Previously, they were duplicated by svn_utf_cstring_to_utf8(), which
allocates the result in a pool even if no actual conversion has been
performed.
For example, check out this block of code, existed in the trunk before:
case opt_encoding:
opt_state.encoding = apr_pstrdup(pool, opt_arg);
break;
Basically I want to avoid or minimise changing behaviour in utf8-isation.
Also this may be cool to introduce an iterpool into the argument handling
loop. In this case it's mandatory to copy them to the right one.
--
Timofei Zhakov
;d prefer to first try this in the branch, then commit
such changes one-by-one.
--
Timofei Zhakov
On Tue, May 27, 2025 at 5:32 PM Timofei Zhakov wrote:
> Hi,
>
> I noticed that there are two different functions in different libraries
> (libsvn_subr and libsvn_client) which are doing almost the same thing. But,
> one in subr is permanently deprecated.
>
> Fine, it was mov
clearly the utf8-converted option arg has to be allocated in the
> result pool in the first place. Why would you do the conversion into an
> iterpool, then copy the result to the result pool? That doesn't make sense.
>
--
Timofei Zhakov
On Wed, May 28, 2025 at 10:32 AM Branko Čibej wrote:
> On 28. 5. 25 00:11, Timofei Zhakov wrote:
>
> See? SEE!!?? I *told* you it was a mess. :D
>>
>> This stuff should all be in libsvn_subr/cmdline.c. I don't even remember
>> any more how this happened. I th
if serf starts using svn's modules. I can try to
support pkgconfig in them if needed.
Thoughts?
--
Timofei Zhakov
code simple one-line functions that wrap
libsvn_cmdline into libsvn_subr, since libsvn_subr should not link with
libsvn_cmdline. I don't see any resolutions yet...
That's it for now...
--
Timofei Zhakov
e svn_opt's one doesn't implement some functionality that svn_client's
does.
--
Timofei Zhakov
nge:
/* Parse the next option. */
- apr_status_t apr_err = apr_getopt_long(os, svn_cl__options, &opt_id,
- *&opt_arg*);
+ apr_status_t apr_err = apr_getopt_long(os, svn_cl__options,
+ &opt_id, *&utf8_opt_arg*);
--
Timofei Zhakov
found a similar issue on GitHub:
github.com/python/cpython/issues/105312
Timofei Zhakov
utf8-cmdline-prototype' branch: follow-up to r1925879.
>
> * subversion/svnadmin/svnadmin.c
> (subcommand_freeze): Convert file contents to UTF-8.
>
>
> -- Brane
>
Okay, fixed!
I agree that this log-message looks much better, but I think it should be
fine to simplify them in such in-branch follow-ups, because it's like an
addition to the base commit.
--
Timofei Zhakov
s. 🙄
>
> Thanks!
>
> -- Brane
>
>
>
> Fixed in r1926563. Not even a one-liner, more of a one-banger. :)
>
Thank you!
I should focus a lot more on such details. Sorry 😅
--
Timofei Zhakov
On Fri, Jun 13, 2025 at 4:10 PM GitBox wrote:
>
> The GitHub Actions job "CMake" on subversion.git/trunk has failed.
> Run started by GitHub user asfgit (triggered by asfgit).
>
> Head commit for run:
> d510c071272942161ccaf298bd2aef9cdcaade62 / Timofei Zhakov <
&
I went ahead and committed in r1926386.
Thanks!
--
Timofei Zhakov
(for some reason my mail client couldn't verify your email and it thinks
it's spam)
--
Timofei Zhakov
_to_target_array3
...or...
3. add svn_opt_args_to_target_array4 doing exactly the same thing as
svn_opt_args_to_target_array3, but without the deprecation marker. However,
this means that utf8 cmd-line would change this function later or even
require svn_opt_args_to_target_array5. None of which look good to me.
Thoughts?
--
Timofei Zhakov
t.
- The documentation (
https://cmake.org/cmake/help/latest/module/FindPkgConfig.html) says
that moduleSpec should be a *bare module name.* Nothing about a path.
- But our autoconf build system does rely on this behaviour already
(/build/ac-macros/serf.m4:153 → serf.m4:163). So, assuming the
cmake
> features much, much harder.
>
>
I prefer to plan my work in a branch, so I can freely break some
functionality, and then commit those changes to trunk one-by-one, and
pretend we never had this branch before. This way, I am getting the work
done, and committed properly. The changes can be reviewed as they are
committed to the trunk.
--
Timofei Zhakov
On Fri, Jun 6, 2025 at 10:16 PM Timofei Zhakov wrote:
> Hi,
>
> I would like to suggest adding a line to svn --version command to display
> the current locale name.
>
> This could be helpful for us receiving or investigating any
> encoding-related bugs, and seems generall
On Sun, Jun 8, 2025 at 4:08 AM Branko Čibej wrote:
> On 6. 6. 25 22:16, Timofei Zhakov wrote:
>
> Hi,
>
> I would like to suggest adding a line to svn --version command to display
> the current locale name.
>
> This could be helpful for us receiving or investigating any
On Sun, Jun 8, 2025 at 12:57 PM Branko Čibej wrote:
> On 8. 6. 25 12:51, Timofei Zhakov wrote:
>
> On Sun, Jun 8, 2025 at 4:08 AM Branko Čibej wrote:
>
>> On 6. 6. 25 22:16, Timofei Zhakov wrote:
>>
>> Hi,
>>
>> I would like to suggest adding a line
On Sun, Jun 8, 2025 at 1:03 PM Daniel Sahlberg
wrote:
>
>
> sön 8 juni 2025 kl. 12:47 skrev Timofei Zhakov :
>
>> On Sun, Jun 8, 2025 at 2:48 AM Branko Čibej wrote:
>>
>>> On 7. 6. 25 19:41, rin...@apache.org wrote:
>>>
>>> Author: rinrab
1 - 100 of 126 matches
Mail list logo
