.
Done in r1692650.
-- Stefan^2.
to be upgraded, IMO.
From: Branko Čibej mailto:br...@wandisco.com
Sent: 23-7-2015 11:02
To: dev@subversion.apache.org mailto:dev@subversion.apache.org
Subject: Re: 1.9.0 minimal Python version
On 23.07.2015 10:30, Stefan
would be
of any benefit)
Regards,
Stefan
normalize --remove-obsoletes.
Regards,
Stefan
@echo off
md testrepo
svnadmin create testrepo
md testout
svn co file:///E:/[delete]SVNTest/testrepo testout
cd testout
REM create test tree
md SDK
md SDK\FooSDK
md SDK\FooSDK\tags
md SDK\FooSDK\trunk
echo Test SDK\FooSDK\trunk\test.txt
md
, so
if a user put the bdb-sources in the default path it would find and use
them like with the previous versions (not sure whether u want that
changed or not given the fact that BDB is deprecated).
Regards,
Stefan
Index: gen_win.py
On 7/21/2015 7:55 AM, Branko Čibej wrote:
On 20.07.2015 16:20, Stefan Hett wrote:
Hi,
following several hours of investigation and discussion on IRC with
danielsh, philipm and bert I believe there to be some issue in the
build generator for Windows.
Running the python command:
python gen
Hi,
I'c the patch was applied to trunk. Thanks. ;-)
Regards,
Stefan
Hi,
[[[
Drop BDB warnings in gen-make, if building without BDB-support.
* build/generator/gen_win.py
(__init__): Remove BDB-warning, if optional 'db' library not found in
self._libraries
* build/generator
On 7/21/2015 7:55 AM, Branko Čibej wrote:
On 20.07.2015 16:20, Stefan Hett wrote:
Hi,
following several hours of investigation and discussion on IRC with
danielsh, philipm and bert I believe there to be some issue in the
build generator for Windows.
Running the python command:
python gen
From: Daniel Shahaf mailto:d...@daniel.shahaf.name
Sent: 19-7-2015 19:12
To: dev@subversion.apache.org mailto:dev@subversion.apache.org
Cc: comm...@subversion.apache.org
mailto:comm...@subversion.apache.org; Stefan Hett
mailto:ste...@egosoft.com
Subject: Re: svn commit: r1691712
there).
I didn't test 1.8 or 1.7 but looking at the code suggests it's not an
issue there since the patch which promoted openssl to a proper
dependency library was added post 1.8.
Regards,
Stefan
Index: gen_win_dependencies.py
to find the right solution.
(note: the issue also exists in 1.9 and currently results in the fact
that building without OpenSSL fails on Windows - assuming this is not a
problem in 1.8, it's a regression of 1.9 compared to 1.8).
Regards,
Stefan
Index: gen_win.py
added patchnotes:
[[[
Fix building SVN under Windows without OpenSSL/Serf.
* build/generator/gen_win.py
(get_win_libs): skip serf/openssl dependencies, if these optional
libs are
not present
]]]
Regards,
Stefan
: '/svn/E
gosoft/!svn/rvr/198196/Foo' path not found
Regards,
Stefan
Hi Stefan^2,
Hi Stefan,
First of all, thank you for the detailed feedback! It is very helpful.
I spent the last two weeks refactoring and reworking the tool. The
main changes:
* explicit --verbose mode, much quieter without it
* progress output
* only one common 'normalize' sub-command
On Wed, Jul 15, 2015 at 12:03 PM, Stefan Hett ste...@egosoft.com
mailto:ste...@egosoft.com wrote:
Hi Stefan^2,
I've just tried to rerun the latest svn-mergeinfo-normalizer.
Running the command svn-mergeinfo-normalizer normalize the
application crashes in local_lookup
On Wed, Jul 15, 2015 at 12:03 PM, Stefan Hett ste...@egosoft.com wrote:
Hi Stefan^2,
I've just tried to rerun the latest svn-mergeinfo-normalizer.
Running the command svn-mergeinfo-normalizer normalize the application
crashes in local_lookup() in missing-branches.c in line 95 due to lookup
sections about building APR, ZLib, and Serf to give some leads
how to build these from source (serf: only TODO-markers)
* INSTALL
documentation updated
]]]
Regards,
Stefan
Bert Huijben wrote:
I'm guessing VC6 still works as that was used in many httpd builds until
recently, but 2002 and 2003
* INSTALL
documentation updated
]]]
Regards,
Stefan
Index: INSTALL
===
--- INSTALL (revision 1691631)
+++ INSTALL (working copy)
@@ -146,7 +146,7 @@
Subversion contains optional support for storing passwords
for SQLite 3.7.12
- added optional-markers to steps which are not required in all cases
- added missing required quotes around SDK-paths which contain spaces
* INSTALL
documentation updated
]]]
Regards,
Stefan
Index: INSTALL
,
Stefan
Index: INSTALL
===
--- INSTALL (revision 1691631)
+++ INSTALL (working copy)
@@ -145,7 +145,7 @@
Subversion contains optional support for storing passwords in
KWallet (KDE 4) or GNOME Keyring
missing required quotes around SDK-paths which contain spaces
* INSTALL
documentation updated
]]]
Regards,
Stefan
Index: INSTALL
===
--- INSTALL (revision 1691631)
+++ INSTALL (working copy)
@@ -151,7 +151,7
Hi Stefan^2,
I've just tried to rerun the latest svn-mergeinfo-normalizer.
Running the command svn-mergeinfo-normalizer normalize the application
crashes in local_lookup() in missing-branches.c in line 95 due to lookup
being null:
if (apr_hash_get(lookup-existing, branch, len))
let me know
On Thu, Jun 25, 2015 at 3:29 PM, Stefan Hett ste...@egosoft.com wrote:
Hi,
as promised, answering the remaining questions now:
Hi Stefan,
First of all, thank you for the detailed feedback! It is very helpful.
I spent the last two weeks refactoring and reworking the tool. The main
changes
On Thu, Jun 25, 2015 at 5:10 PM, Stefan Hett ste...@egosoft.com wrote:
Hi,
I'm dealing with one remaining case svn-mergeinfo-normalizer normalize
doesn't seem to be able to handle yet. Would it be possible to add support
for this?
Case: Eliminate incorrect mergeinfos of pre-branch
check-ctypes-python
./get-deps.sh
Results:
All tests passed.
GPG Signatures committed to the dist/dev/subversion repository.
-- Stefan^2.
almost as long as a full soak
period in the Good Old Days.
-- Stefan^2.
the format file (should never happen, but ...)
-- Stefan^2.
*From:* Stefan Fuhrmann stef...@apache.org
*Sent:* Tuesday, June 30, 2015 9:50 PM
*To:* comm...@subversion.apache.org
Author: stefan2
Date: Tue Jun 30 19:50:46 2015
New Revision: 1688511
URL: http://svn.apache.org/r1688511
are always sharded.
r1688511 should handle them.
Thanks for noticing!
-- Stefan^2.
Hi Stefan,
If you have a working build environment for Subversion,
you might have a look at this branch:
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer
It provides a new tool that you might find useful:
./tools/client
On Thu, Jun 25, 2015 at 12:59:16PM +, Bert Huijben wrote:
I think it would help future conflict resolve code if we call the conflict
resolver only once per conflicted path. This would allow providing all
conflict details (text, prop | tree) to a user, which can then really
apply resolve
while before it had to commit up to 400 nodes changes... So this to us
is a really significant improvement.
Regards,
Stefan
Hi
On Wed, Jun 24, 2015 at 4:58 PM, Stefan Hett ste...@egosoft.com
mailto:ste...@egosoft.com wrote:
Hi,
hope it's ok to discuss this on this list rather than the users
list (since the tool is not part of a released version):
I'm looking at the following output from mergeinfo
at r184223). So these should simply be eliminated, no?
Regards,
Stefan
Hi Stefan^2,
Hi Stefan,
If you have a working build environment for Subversion,
you might have a look at this branch:
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer
It provides a new tool that you might find useful:
./tools/client-side/svn-mergeinfo-normalizer
On Tue, Jun 23, 2015 at 11:59:25PM +, Bert Huijben wrote:
Update and merge report ‘obstructed; for different reasons… But are within
itself pretty consistent, and the documentation of obstructed in svn_wc.h
supports both implementations.
Can you explain how the reasons for reporting an
On Wed, Jun 24, 2015 at 10:21 AM, Stefan Hett ste...@egosoft.com wrote:
Hi Stefan^2,
Hi Stefan,
If you have a working build environment for Subversion,
you might have a look at this branch:
https://svn.apache.org/repos/asf/subversion/branches/svn-mergeinfo-normalizer
It provides a new
On Wed, Jun 24, 2015 at 02:01:59PM +0200, Bert Huijben wrote:
Why only 3 values now?
I remember you tweaking the code to pass all 4 values a few weeks (months?)
ago.
The end goal is 4 values, yes. I'm still unsure how to name the
corresponding output parameters though. So, for now, I've
)
Regards,
Stefan
?xml version=1.0 encoding=UTF-8?
log
logentry
revision=191090
authorStefan/author
date2015-02-06T10:02:26.725485Z/date
paths
path
prop-mods=true
text-mods=false
kind=dir
action=M/XRebirth/trunk/path
path
prop-mods=true
text-mods=false
kind=dir
action=M
On Wed, Jun 24, 2015 at 4:58 PM, Stefan Hett ste...@egosoft.com wrote:
Hi,
hope it's ok to discuss this on this list rather than the users list
(since the tool is not part of a released version):
I'm looking at the following output from mergeinfo-normalizer analyse:
Trying to elide
On Tue, Jun 23, 2015 at 2:33 PM, Stefan Hett ste...@egosoft.com wrote:
Hi Stefan^2,
On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett ste...@egosoft.com wrote:
Hi Stefan,
thanks for taking the time to write that tool.
I've scheduled a time-slot to check this out/test on our side
Hi Stefan^2,
On Thu, Mar 26, 2015 at 2:21 PM, Stefan Hett ste...@egosoft.com
mailto:ste...@egosoft.com wrote:
Hi Stefan,
thanks for taking the time to write that tool.
I've scheduled a time-slot to check this out/test on our side.
Unfortunately, our current project plan
tests with the normalizer-tool. Indeed it was a DLL-mismatch.
Also thanks for updating the branch @Stefan^2.
Regards,
Stefan
On Tue, Jun 23, 2015 at 01:34:59PM +0200, Bert Huijben wrote:
I don't think this label accurately describes the intended case of this test.
Personally I think it is better to add mergeinfo on the TC-victim then to
*add* non-inherital mergeinfo to both the direct ancestor *and* inheritable
is only relevant to -g blames we shouldn't apply it to other
blame invocations.
r1686888 now restricts the hack to -g mode.
-- Stefan^2.
On Mon, Jun 22, 2015 at 06:22:50PM +0200, Bert Huijben wrote:
This assertion triggers in quite a few testcases on all buildbots.
[[
At least one test FAILED, checking E:\svn-local\tests\tests.log
FAIL: externals_tests.py 68: check file external recorded info
FAIL: info_tests.py 9: svn info
(incorrectly?) be added?
Regards,
Stefan
familiar with the build scripts, can someone point me to
where this library-dependency might (incorrectly?) be added?
Regards,
Stefan
On Fri, Jun 19, 2015 at 8:37 PM, Evgeny Kotkov evgeny.kot...@visualsvn.com
wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
Well, it works based on SVN's concept of OS-side readonlyness.
svnadmin_tests.py 51 passes on Windows.
Did you try the test after doing 'svn merge -c
On Fri, Jun 19, 2015 at 11:50 AM, Branko Čibej br...@wandisco.com wrote:
On 18.06.2015 21:58, Stefan Fuhrmann wrote:
One key design element is that the batch fsync
container owns the open files and will open them
only once. So, it can not only guarantee that we
don't need to reopen files
On Fri, Jun 19, 2015 at 2:26 PM, Evgeny Kotkov evgeny.kot...@visualsvn.com
wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
And the regression should be fixed.
[...]
There is a trivial fix: Try to acquire the lock and fall back to the
non-locking behavior if you get
On Mon, Jun 15, 2015 at 1:20 PM, Julian Foad julianf...@btopenworld.com
wrote:
My understanding of the situation is as follows. I'm not adding much
to what Philip and Stefan have already diagnosed, I just want to say
how I see it as well, and allow others to confirm it or correct me
On Thu, Jun 18, 2015 at 3:24 PM, Evgeny Kotkov evgeny.kot...@visualsvn.com
wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
Sorry, my bad, I was wrong there. I only remembered that we had and still
have the pack/hotcopy race condition in 1.8 and then I saw the recursive
.
-- Stefan^2.
On Tue, Jun 16, 2015 at 11:55 PM, Evgeny Kotkov evgeny.kot...@visualsvn.com
wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
That makes we wonder how we prevent packing in old format repositories.
We know that hotcopying while packing can corrupt the destination repo
On Tue, Jun 16, 2015 at 11:01:36PM +0200, Stefan Fuhrmann wrote:
I feel this is something we need to talk about privately in Berlin.
I'll make very sure indeed you two get to share a double bedroom at the hotel.
Promise.
are at it, let's detect pack operations during
hotcopy (compare pack status before after the hotcopy).
Then we can at least warn the user of older format repos
that their hotcopy is possibly corrupt now.
How does that sound?
-- Stefan^2.
On Mon, Jun 15, 2015 at 5:36 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 12 June 2015 at 15:11, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 29 May 2015 at 18:55, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
On Tue, Jun 16, 2015 at 9:38 PM, Branko Čibej br...@wandisco.com wrote:
On 16.06.2015 20:49, Stefan Fuhrmann wrote:
Once we are at it, let's detect pack operations during
hotcopy (compare pack status before after the hotcopy).
Then we can at least warn the user of older format repos
Hey there,
One of the links recently provided by Daniel Klima pointed
to a way to enable write caching even on USB devices.
So, I could use my Windows installation for experiments now
without the risk of brick-ing 2 grand worth of disks by pulling
the plug tens of times.
-- Stefan^2.
TL;DR
a better approximation of
what users may -g expect to return.
I also do have an idea of what an ideal -g result would look
like but that requires a different API and / or client-side logic.
But that would be a separate topic.
-- Stefan^2.
On Fri, May 29, 2015 at 6:23 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 29 May 2015 at 18:55, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
On Fri, May 29, 2015 at 4:14 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 28 May 2015 at 20:47, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
On Fri, May 29, 2015 at 4:54 PM, Evgeny Kotkov evgeny.kot...@visualsvn.com
wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
However, it does not tell you anything about consistency with outside
parties, say some svnsync'ed repository. The problem is that Windows may
end up
.
As it is now, the svn_uri_is_canonical() and the
svn_dirent_canonicalize()/svn_uri_canonicalize() don't really match.
Stefan
--
___
oo // \\ De Chelonian Mobile
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/The coolest interface to (Sub)version control
/_/ \_\ http
the svn_dirent_canonicalize() and svn_uri_canonicalize()
APIs are for.
Problem is: in that case they don't work:
$ svn list file:///c:Software/SourceCodeRepository
try that with an svn build from the 1.9.x branch and you'll get an
exception.
Stefan
--
___
oo // \\ De Chelonian
to talk about in Berlin.
-- Stefan^2.
committed, reviewed and
approved for 1.9.x.
Apart from changing the API (renamed error code),
this patch is a mere bugfix. Having an RC3 for that
will extend the soak period for 1.9.0 by at most 1 week.
So, there is no point in holding back rc2, which will
restart a full soak period.
-- Stefan^2.
On Wed, May 27, 2015 at 6:35 PM, Julian Foad julianf...@gmail.com wrote:
Stefan Fuhrmann wrote:
Alright. I gave it a bit more thought now.
Whenever we encounter this mismatch, something pretty
bad likely happened to the repo - such as a failed restore
attempt. In turn, we can expect those
cases, the revision data should be corrupt, e.g. just be
empty files.
Ideally, you place the repo on some SAN and keep that
running such that HW buffer effects don't play a role here.
-- Stefan^2.
On 28 May 2015 6:54 pm, Ivan Zhakov i...@visualsvn.com wrote:
Did
you able to reproduce
On Thu, May 28, 2015 at 9:54 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
In the future, we should implement step 1 as simple
non-fsync'ing file operations. Then explicitly sync every
file, and on POSIX the folders, once. Step 2 does
I would like to start transitioning away from svn_wc_conflict_description2_t
in public APIs and introduce a higher-level API to eventually replace it.
My end goal is to use an opaque type with methods that make it possible
to implement conflict resolution in a way that is easier to use.
For
On Fri, May 29, 2015 at 4:14 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 28 May 2015 at 20:47, Stefan Fuhrmann stefan.fuhrm...@wandisco.com wrote:
Hi all,
Most of us would agree that way we fsync FS changes
in FSFS and FSX is slow (~10 commits / sec on a SSD,
YMMV) and not even all changes
and the
txn ID be wasted. In 'svnadmin load', however, we
save the 2x fsync dance with the 'txn-current' file.
So, I suggest to implement svn_io__batch_fsync_t
and use that for all durable FS modification, explicitly
excluding in-txn operations.
Does that sound like a plan?
-- Stefan^2.
On Thu, May 28, 2015 at 6:52 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 28 May 2015 at 19:25, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
On Thu, May 28, 2015 at 5:54 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 28 May 2015 at 18:45, stef...@apache.org wrote:
Author: stefan2
are really sure that this
code required.
We need to change to change the way we use fsync anyway.
I have a patch set for FSX sitting around for weeks now that
reduces the overall number of fsyncs per commit from 8 to 2.
I'll explain it in a different post.
-- Stefan^2.
On Wed, May 27, 2015 at 8:14 PM, Philip Martin philip.mar...@wandisco.com
wrote:
Julian Foad julianf...@gmail.com writes:
Stefan Fuhrmann wrote:
* clear the rep-cache.db
Clearing the cache and continuing operation may make subsequent
commits much larger than they should
that the current workflow is horribly inefficient but
I think we can change that. I'll talk about that in a separate
thread.
-- Stefan^2.
more noticeable?
-- Stefan^2.
on that one. I guess
it is very unlikely that the mismatch has legitimately been
caused by e.g. a SHA1 collision. Maybe, we should reset /
clear the rep-cache.db at that point and say so in the warning.
-- Stefan^2.
, but could
be if we release 1.8.14 before 1.9.0.
That change is now approved for both 1.8.x and 1.9.x.
-- Stefan^2.
On Wed, May 27, 2015 at 12:11 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 27 May 2015 at 12:49, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
On Wed, May 27, 2015 at 11:28 AM, Ivan Zhakov i...@visualsvn.com
wrote:
It seems directory cache checked twice in function
On Mon, May 25, 2015 at 11:26 PM, Julian Foad julianf...@btopenworld.com
wrote:
Stefan Sperling wrote:
Is it worth extending the comment in the code with information from
this thread?
IMO, Yes it is worth it.
O.k. Done in r1681960 and r1681965.
-- Stefan^2.
On Wed, May 27, 2015 at 1:11 PM, Julian Foad julianf...@gmail.com wrote:
Stefan Fuhrmann wrote:
Julian Foad wrote:
@@ -2262,14 +2264,20 @@ get_shared_rep(representation_t **old_re
/* A simple guard against general rep-cache induced corruption. */
if ((*old_rep)-expanded_size
to Stefan and I believe I can explain. Reversibility is not a
hard requirement on trunk or 1.9 at present, since we store the full
key, but may be a requirement in future. This code is for keys that fit
in the fingerprint and when generating the fingerprint from such keys we
want to avoid
On Mon, May 18, 2015 at 1:16 AM, Daniel Shahaf d...@daniel.shahaf.name
wrote:
Stefan,
How about the following patch to sanity check the rev file footer?
Committed as r1680460 with a minor modification.
Index: subversion/libsvn_fs_fs/low_level.c
On Mon, May 18, 2015 at 11:27 AM, Ivan Zhakov i...@visualsvn.com wrote:
On 18 May 2015 at 02:16, Daniel Shahaf d...@daniel.shahaf.name wrote:
Stefan,
How about the following patch to sanity check the rev file footer?
[...]
The error looks like this:
subversion/libsvn_fs_fs
On Wed, May 20, 2015 at 08:36:23AM +0200, Stefan Fuhrmann wrote:
On Tue, May 19, 2015 at 8:25 PM, Philip Martin philip.mar...@wandisco.com
wrote:
I talked to Stefan and I believe I can explain.
Yes.
Exactly.
Is it worth extending the comment in the code with information from
this thread?
On Mon, May 18, 2015 at 01:54:03PM +, Lorenz wrote:
Hi all,
I'm getting desperate because I think I've spotted a bug/regression in
svn since 1.8.11 and in spite of several post about the topic (both to
users and dev) noone seem interested in verifying or rejecting my
report.
I can
On Sat, May 16, 2015 at 7:45 PM, Ivan Zhakov i...@visualsvn.com wrote:
On 16 May 2015 at 07:48, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
On Fri, May 15, 2015 at 7:25 PM, Philip Martin
philip.mar...@wandisco.com
wrote:
Another issue: find_entry() now calls drop_entry() in more
On Thu, May 14, 2015 at 2:37 PM, Branko Čibej br...@wandisco.com wrote:
On 13.05.2015 19:04, Ivan Zhakov wrote:
[adjusting subject to make it valid vote thread]
On 13 May 2015 at 19:23, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
Hi there,
Ivan has reviewed my recent
On Wed, May 6, 2015 at 11:07 AM, Philip Martin philip.mar...@wandisco.com
wrote:
Stefan Fuhrmann stefan.fuhrm...@wandisco.com writes:
Here is what I believe causes the different behaviour between
test runs. To support read function that may block, e.g. wait for
network buffers to flush
, and that can corrupt the cache.
If we use read-write locks then when read detects a fingerprint
collision it cannot modify the cache to clear the collision, it will
have to return NULL and leave the entry in the cache.
You are absolutely right. Fixed in r1679681.
-- Stefan^2.
, there is no reason that you have to. As a
result, script users only need to know the path and have those new
rights to manage branches tags. No need to give them access to
their contents.
-- Stefan^2.
to see 2 more +1s for the branch-/trunk
merge.
-- Stefan^2.
On Wed, May 13, 2015 at 7:04 PM, Ivan Zhakov i...@visualsvn.com wrote:
[adjusting subject to make it valid vote thread]
On 13 May 2015 at 19:23, Stefan Fuhrmann stefan.fuhrm...@wandisco.com
wrote:
Hi there,
Ivan has reviewed my recent membuffer cache
key handling changes, corrected
be updated accordingly (always the same reqs as a COPY
+ DELETE).
-- Stefan^2.
Index: subversion/mod_authz_svn/mod_authz_svn.c
===
--- subversion/mod_authz_svn/mod_authz_svn.c (revision 1679144)
+++ subversion/mod_authz_svn
.
-- Stefan^2.
On Tue, May 12, 2015 at 06:14:16PM +0300, Evgeny Kotkov wrote:
Subversion 1.9.0-rc1 changed the behavior of commands such as 'svn st'
in situations the wc.db workqueue is not empty, i.e., contains stale items.
These read-only commands no longer fail with SVN_ERR_WC_CLEANUP_REQUIRED:
Any
On Thu, May 07, 2015 at 03:19:55PM +0200, Bert Huijben wrote:
Your log message documents this change as 'This way, the hash parser's error
message is preserved.', which is not what this change does.
The docstring of svn_error_quick_wrap fooled me. I've reverted
r1678151 and improved the
On Sun, May 10, 2015 at 04:05:16PM +, Daniel Shahaf wrote:
Subversion 1.9.0-beta1 may accept invalid SSL certificates presented by
servers in certain conditions: if both --non-interactive and --trust-foo
were passed, and the certificate has two failures, both the 'foo'
failure and some
on merge policies and branching depth, that might
be a realistic scenario.
-- Stefan^2.
1201 - 1300 of 4519 matches
Mail list logo
