t 08:25:32PM +0300, Sergey Raevskiy wrote:
> > I've noticed that in some cases a working copy can become inoperable
> > after merge text conflict resolution with `svn_wc_conflict_choose_merged'
> > option.
> >
> > The problem can occur in the following scenario:
> &g
I've noticed that in some cases a working copy can become inoperable
after merge text conflict resolution with `svn_wc_conflict_choose_merged'
option.
The problem can occur in the following scenario:
1. There is a text conflict, that is resolved with
`svn_wc_conflict_choose_merged' option
Hello!
I've attached a patch which adds a new option (--include-parents) to 'svnadmin
dump'. This option works with existing --include option and includes parent
nodes for nodes specified in --include option.
This should fix the mentioned case.
The option doesn't work with globbing for now,
Hello!
I've spent some time examining r1866425 [1] ('Last-Modified' header) and I
would like to suggest a patch with some rework related to this code.
I see two main problems in r1866425: usage of the pointer comparison (which is
hackish and relies on the implementation of parse_uri()) and using
PM Stefan Sperling wrote:
>
> On Thu, Aug 15, 2019 at 08:14:43PM +0300, Sergey Raevskiy wrote:
> > > /* if an authenticated username is present, attach it to the FS */
> > >if (r->user)
> > > @@ -2503,6 +2529,14 @@ get_resource(request_rec *r,
> &g
> /* if an authenticated username is present, attach it to the FS */
>if (r->user)
> @@ -2503,6 +2529,14 @@ get_resource(request_rec *r,
>apr_pool_cleanup_register(r->pool, cleanup_baton, cleanup_fs_access,
> apr_pool_cleanup_null);
>
> + /* We
Great!
I have tried to make a patch to fix #4672, but it didn't work
right away. Going to look again later.
On Mon, Feb 18, 2019 at 1:39 PM Julian Foad wrote:
>
> Thank you, Sergey! Committed and proposed for backport.
>
> A similar (but not the same) problem exists with copies in "svnrdump
n_tests.py
(dump_include_copied_directory): New.
(test_list): Add new test to table.
Patch by: sergey.raevskiy{_AT_}visualsvn.com
]]]
On Fri, Feb 8, 2019 at 6:27 PM Julian Foad wrote:
>
> Sergey Raevskiy wrote:
> > > Ping! Sergey or anyone, are you able to investigate this?
> >
> > He
; > contents. That sounds to me like a bug -- it is not the behaviour I
> > would expect.
> >
> > I see that the regression tests only test with an empty source directory.
> > subversion/tests/cmdline/svnadmin_tests.py : dump_exclude_copysource()
> > etc.
&g
Hi!
I've attached a patch that adds '--include/--exclude' options to 'svnadmin
dump'. These options work similarly to 'svndumpfilter include/exclude'
but provide proper handling of 'copy from' paths.
Consider the following example with svndumpfilter:
[[
$ svnadmin create /repo
$ svn mkdir -m ""
After digging in some disassembly, I've guessed the [libsvn_subr-1.dll+0xc4c20]
as svn_relpath_join() which is called with BASE == NULL. So, the crash might
be caused by the same issue as in [1] which was already fixed in r1702198 [2].
[1] http://svn.haxx.se/dev/archive-2015-09/0070.shtml
[2]
Thanks for the reviews!
If you want to force fail because of the existing directory, I suggest
you create a directory and then do the equivalent of 'chmod -w' on it.
Unfortunately, making the directory unwritable will cause svn_repos_create()
to fail *before* attempting the FS creation and the
After a little discussion with Daniel on IRC I've decided to use
'compatible-version' approach. Setting 'compatible-version' to 1.0.0 should
force to fail creation of new FSFS filesystem, since it first appeared in
Subversion 1.1. This should also be true for FSX (or any other hypothetical
Wouldn't it be easier, and a smaller patch, to add a check in
svn_repos_create that the FS type is valid /before/ creating the
repository structure? This would also avoid adding yet another public API.
As I understand there is no public API for checking if FS-type is valid and
corresponding FS
Hi!
I've noticed inconsistency in svn_repos_create() behavior. Despite the fact
that creation of repositories over empty directories is allowed, in some cases
this function will remove an empty directory that existed before repository
creation.
I've attached the patch with test and fix.
[[[
Коллеги,
для задачи K531 на нужно утвердить следующие тексты:
1) Текст для ситуации, когда post-lock hook выдал ошибку на master
(при выполнении svn lock через slave)
Keyword: MSG_VDFS_POST_LOCK_HOOK_ERROR
Сейчас:
[[[
An error occurred with post-processing of lock operation.
Repository: master
Please ignore this e-mail (I accidentally sent it to the wrong mailing list).
Hi!
I've noticed an improper pool usage in FSFS code. The svn_lock_t * object is
created in RESULT_POOL, but its fiels are not gettting pstrdup'ed.
The patch with fix is attached.
Log message:
[[[
* subversion/libsvn_fs_fs/lock.c
(lock_body): Fix pool usage. Call apr_pstrdup() when
I think info-path is already in the correct pool, it's the result of
processing the the input path through svn_fspath__canonicalize using
result_pool.
Yes, INFO-PATH is alocated in correct pool already. I've attached a new
version of my patch (log message remains the same).
Index:
Hi!
Recently I've spent some time investigating how lock and unlock are implemented
in FSFS and can suggest the following simplification. I attempted just to make
this part clearer and a new code is intended to behave exactly the same.
The patch is attached.
Log message:
[[[
Simplify
Recently I've spent some time investigating how lock and unlock are
implemented in FSFS and can suggest the following simplification. I
attempted just to make this part clearer and a new code is intended to
behave exactly the same.
It's not exactly the same, index files are written/deleted
I suspect the implementation is now more complicated than necessary.
walk_locks and walk_locks_baton could be removed, walk_digest_files
could be renamed to indicate that only a single digest file is accessed.
The callers of walk_locks would call the renamed function directly.
Yes. I'm going
This is issue 2507
http://subversion.tigris.org/issues/show_bug.cgi?id=2507
Commit does not remove locks, lock removal is a separate step after
commit. However that doesn't work well when a commit removes a locked
item, after such a commit the remaining lock is invalid and should not
Hi!
I've discovered interesting thing about the svn_fs_fs__get_locks() function.
In some unusual, but not impossible scenarios this function could report the
same lock multiple times: there should be the path with lock, and one of its
children should be locked as well (see the test in attached
I suspect the implementation is now more complicated than necessary.
walk_locks and walk_locks_baton could be removed, walk_digest_files
could be renamed to indicate that only a single digest file is accessed.
The callers of walk_locks would call the renamed function directly.
Yes. I'm going
I committed the test using /bin/sh, anything else is a lot more work and
possibly more likely to fail than to find a system without /bin/sh.
I'm agree, other options seems to be less reliable and much more complicated.
Finally, there is well-known practise of using /usr/bin/env (e.g.
Thanks for the review! I really messed up the test.
How is that going to work? exit 0 is not a valid hook script. It
might work with an additional /bin/sh but that is not portable.
This will actually work on Windows, but yes, it isn't portable.
Ah! The fs layer does not run any hooks,
Hi!
I've discovered another crash in lock-related code. Usage of deprecated API
svn_fs_access_add_lock_token() function leads to crash when pre-commit hook is
getting executed.
Function svn_fs_access_add_lock_token() simply calls
svn_fs_access_add_lock_token2() and passes some magic value
,
svn_fs_fs__lock): Initialize the lb.infos field before calling to
svn_fs_fs__with_write_lock().
(unlock_body,
svn_fs_fs__unlock): Same.
Patch by: Sergey Raevskiy sergey.raevskiy{_AT_}visualsvn.com
]]]
Index: subversion/libsvn_fs_fs/lock.c
The problem can be fixed by merging subversion/trunk:r1553501,1553556,1559197
with --accept=theirs-conflict (+ adding a missing svn_error_t *err;
declaration).
This worked for me, all tests passed, including new one (Windows 8,
httpd 2.2.27, svn 1.8.8, http x fsfs).
BTW, should this be filed
+ # Around trunk@1581815 refreshing of DAV lock fails with error
+ # '412 Precondition Failed'
You say it starts to fail at r859583 so how is 1581815 relevant?
I've just tried to say that problem is still actual at r1581815.
and regards,
Sergey Raevskiy
Index: subversion/tests/cmdline/lock_tests.py
===
--- subversion/tests/cmdline/lock_tests.py (revision 1583942)
+++ subversion/tests/cmdline/lock_tests.py (working copy)
@@ -2178,6 +2178,48 @@ def
this!
On Thu, Mar 20, 2014 at 3:04 PM, Bert Huijben b...@qqmail.nl wrote:
-Original Message-
From: Sergey Raevskiy [mailto:sergey.raevs...@visualsvn.com]
Sent: donderdag 20 maart 2014 09:47
To: Subversion Development
Subject: [PATCH] Fix lock timeout values handling in libsvn_ra_serf
Hi
.
* subversion/libsvn_ra_serf/lock.c
(locks_closed): Parse XML element value as TimeType
Patch by: Sergey Raevskiy sergey.raevskiy{_AT_}visualsvn.com
]]]
[1] https://tools.ietf.org/html/rfc4918
Thanks and regards,
Sergey Raevskiy
Index: subversion/libsvn_ra_serf/lock.c
Rainer, can you check if the patch below works for you?
If so, we can merge both patches and put the new code into an #else block.
...
+ for (j = 0; j 4; j++)
+val |= (path[i + j] j);
...
It seems that this sode should be:
+ for (j = 0; j 4; j++)
+val |= (path[i
35 matches
Mail list logo
