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
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
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
ignore_content_type,
ignore_properties,
properties_only,
- FALSE /*use_git_diff_format*/,
+ use_git_diff_format,
pretty_print_mergeinfo,
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
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 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
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 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
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
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
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:
> > >
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.
> >
>
:)
> 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
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
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
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 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...@
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
/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
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
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
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
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:
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 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
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
> "${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
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
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 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
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 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'
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
; 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
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
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
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
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
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 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 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
>
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
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
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.
>>
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 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
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
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
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
because the targets.cmake file didn't regenerate. Did you run
`./gen-make.py -t cmake`?
Thanks.
--
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
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 :
>>
>>
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
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?
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
c-libs` field.
>
> Affected only Windows.
> ]]]
>
> Thanks!
Committed myself in r1918596.
--
Timofei Zhakov
64 matches
Mail list logo
