> svn_client_conflict_option_incoming_added_dir_merge,
> -description,
> +_("Merge the directories"), description,
> resolve_merge_incoming_added_dir_merge);
> }
>
> [..]
>
>return SVN_NO_ERROR;
> @@ -7644,8 +7669,8 @@
> configure_option_incoming_added_dir_replace_and_merge(
>add_resolution_option(
> options, conflict,
> svn_client_conflict_option_incoming_added_dir_replace_and_merge,
> -description,
> -resolve_merge_incoming_added_dir_replace_and_merge);
> +_("Replace and merge"),
> +description, resolve_merge_incoming_added_dir_replace_and_merge);
> }
Same as before. Where is this different to
svn_client_conflict_option_incoming_added_dir_merge?
Great work btw. :-)
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On Thu, Oct 13, 2016 at 04:46:55PM +0200, Patrick Steinhardt wrote:
> Is there by any chance a tool which helps generating this tedious
> list?
There are some but I cannot tell which is best and how well these are working.
On Thu, Oct 13, 2016 at 03:46:32PM +0200, Patrick Steinhardt wrote:
> * subversion/include/svn_client.h:
> - new function `svn_client_conflict_option_get_label`
> * subversion/libsvn_client/conflicts.c:
> - svn_client_conflict_option_t: add label
> - add_resolution_option: add label argument
On Thu, Oct 13, 2016 at 03:01:39PM +0200, Ivan Zhakov wrote:
> I suggest to change behavior to something like the following:
> [[[
> $ svn resolve
> Searching tree conflict details for
> 'D:\ivan\svn\test-wc\add-versus-add\foo' in repository:
> Checking r5... done
> Tree conflict on
On 10/12/2016 5:00 PM, 'Stefan Sperling' wrote:
> I'm actually surprised that we made this change in 1.7.
>
> If 'svn checkout' sees an existing directory the most likely situation is
> that the user has made a mistake. Leaving behind a working copy full of
> tree conflicts i
On 12.10.2016 22:22, Evgeny Kotkov wrote:
Stefan Fuhrmann <stef...@apache.org> writes:
There are a number of backport proposals that only need one more +1.
Since the Berlin hackathon is going on and we feel like preparing the
next patch release(s) soon-ish, please review and vote.
On 10/13/2016 11:08 AM, Stefan wrote:
> On 10/10/2016 11:39 PM, Stefan wrote:
>> On 10/10/2016 6:12 PM, Ivan Zhakov wrote:
>>> On 10 October 2016 at 17:53, Stefan <luke1...@posteo.de> wrote:
>>>> On 8/28/2016 11:32 PM, Bert Huijben wrote:
>>>>&
On 10/10/2016 11:39 PM, Stefan wrote:
> On 10/10/2016 6:12 PM, Ivan Zhakov wrote:
>> On 10 October 2016 at 17:53, Stefan <luke1...@posteo.de> wrote:
>>> On 8/28/2016 11:32 PM, Bert Huijben wrote:
>>>>> -Original Message-
>>>>> From: Dan
Hi there,
There are a number of backport proposals that only need
one more +1. Since the Berlin hackathon is going on and
we feel like preparing the next patch release(s) soon-ish,
please review and vote.
-- Stefan^2.
On Wed, Oct 12, 2016 at 04:49:55PM +0200, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: Stefan Sperling [mailto:s...@elego.de]
> > Sent: woensdag 12 oktober 2016 16:37
> > To: Patrick Steinhardt <patrick.steinha...@elegosoft.com>
> >
On Wed, Oct 12, 2016 at 04:28:05PM +0200, Patrick Steinhardt wrote:
> Hi,
>
> attached is a patch to reject checkouts to already existing
> directories when `--force` is not given. This is according to
> `svn co --help`.
>
> [[
> Reject checkout to existing paths without force
>
> *
On Wed, Oct 12, 2016 at 03:38:02PM +0200, Patrick Steinhardt wrote:
> Hi,
>
> please find attached a patch pulling out the short descriptions
> of conflict resolution options from the client and puts them into
> libsvn_client.
>
> [[
> Move conflict resolution options' labels out of the client
>
On 10/12/2016 12:58 PM, Ivan Zhakov wrote:
> On 12 October 2016 at 12:48, Stefan <luke1...@gmx.de> wrote:
>> Hi,
>>
>> hope this patch is correct... As far as I see the number of elements is
>> off by one here:
>>
>> [[[
>> Allocate the co
Hi,
hope this patch is correct... As far as I see the number of elements is
off by one here:
[[[
Allocate the correct number of element entries.
* subversion/libsvn_client/conflicts.c
(svn_client_conflict_text_get_resolution_options): Correct number of array
entires.
]]]
Regards,
Stefan
On Wed, Oct 12, 2016 at 12:29:55PM +0200, Dario Niedermann wrote:
> That is true. I was mostly wondering if Subversion was (for example)
> running hook scripts via /usr/bin/env; so that it's expected for any
> flags on the shebang line to cause errors. Or if I'm onto something
> and opening a bug
On Wed, Oct 12, 2016 at 12:04:03PM +0200, Dario Niedermann wrote:
> The community guide on Subversion's website says it's OK to ask on
> dev@ if a report on a possible issue with svn doesn't goes unanswered
> on users@. Considering that the only reply I got on users@ was from
> someone who
issue
was fixed for you and there's no longer any problem. May I suggest you
just bump your post on the users list in order to see if someone else
picks it up there?
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On 10/10/2016 6:12 PM, Ivan Zhakov wrote:
> On 10 October 2016 at 17:53, Stefan <luke1...@posteo.de> wrote:
>> On 8/28/2016 11:32 PM, Bert Huijben wrote:
>>>> -Original Message-
>>>> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
&
On 8/28/2016 11:32 PM, Bert Huijben wrote:
>
>> -Original Message-
>> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>> Sent: zondag 28 augustus 2016 20:23
>> To: Stefan <luke1...@posteo.de>
>> Cc: dev@subversion.apache.org
>> Subject
with backports, give a shout
> (here on dev@, or on private@ if necessary).
>
> For background on the migration, see
> https://issues.apache.org/jira/browse/INFRA-12289.
>
Thanks for taking care about that, Johan.
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On Fri, Sep 30, 2016 at 07:09:15PM +0300, Evgeny Kotkov wrote:
> Hi,
>
> I was thinking about which options should be offered by the tree conflict
> resolver in a common case with a catch-up merge when a file is moved
> away in trunk and edited on the branch. (Limiting the scope to a case
> when
On Sat, Sep 24, 2016 at 08:34:05PM -0400, Paul Hammant wrote:
> Can I put the item in Jira and y'all mark it as a 2.0 feature.
Just filing a ticket in the issue tracker won't lead to any sort of progress.
You'll need to convince us why *we* want this feature and do the work,
or why we should
On Sat, Sep 17, 2016 at 06:52:44AM +, Daniel Shahaf wrote:
> I think end-users do care about the error code. We print it out in the
> command-line tools too and one of the reasons for that is so scripts can
> parse it.
>
> Moreover, as per the TODO's in the patch, this is groundwork for
On Fri, Sep 16, 2016 at 03:42:58AM +, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Fri, Sep 09, 2016 at 06:44:51 +:
> > 3. Add to svn_commit_info_t an svn_error_t representation of the error
> > chain that svn_commit_callback_t::post_commit_err summarizes,
>
> Patch attached.
>
> The
On 9/10/2016 10:35 AM, Julian Foad wrote:
Julian Foad wrote:
On 06/09/16, Stefan Hett wrote:
What still is unclear to me is that SVN handles the case when I do an
auto merge but not when using the cherry pick merge. [...]
An auto merge doesn't try to merge back a revision that it can
On 08.09.2016 18:51, Daniel Shahaf wrote:
Stefan Fuhrmann wrote on Thu, Sep 08, 2016 at 17:51:47 +0200:
It appears that it might be very hard to get such data into the
repository because we use the same parser function in e.g. the
network layer and the editor drivers. Not sure we all for MD5s
e we all for MD5s etc.
to be missing in all relevant places.
That said, it is at least conceivable that some all-0 SHA1 snug in
in an earlier version (1.5?) as a result of some inconsistent code.
Those occurrences would be dormant and inconsequential pre 1.9
and they should stay that way. Therefore, I proposed r1759686
for backporting.
-- Stefan^2.
On 9/5/2016 10:53 PM, Julian Foad wrote:
On 05/09/16 10:55, Stefan Hett wrote:
On 8/22/2016 5:51 PM, Stefan Hett wrote:
Hi,
as per stsp's suggestion, sending this to the dev list.
I've reduced a problem we've been having with some merge operations on
our main repository from time to time
ort.
If it would be of any help, I could do some performance measurements
with the two approaches on our repository to get some real world numbers
to work with.
--
Regards,
Stefan Hett
On 8/22/2016 5:51 PM, Stefan Hett wrote:
Hi,
as per stsp's suggestion, sending this to the dev list.
I've reduced a problem we've been having with some merge operations on
our main repository from time to time down to the repro script
attached to this JIRA issue [1] (test_obstruction.bat
via the API,
but they're useful when editing revision files by hand, and in any case
invalid on-disk data should not cause segfaults.
I'll look into this after the current APR and FSFS fixes
for svnadmin pack are completed. Should not be too
difficult to figure out the correct behaviour.
-- Stefan^2.
On Mon, Aug 29, 2016 at 02:44:28PM +0200, Stefan Sperling wrote:
> If you have time to fix it, please do!
I got an opportunity to fix this myself: http://svn.apache.org/r1758269
> Log:
> > Fix issue #4652 which shows how to trigger an assertion failure in
> > svn_dirent_get_absolute() by passing invalid input on the command line.
> >
> > Report a proper error message instead.
> >
> > * subversion/libsvn_subr/dirent_uri.c
> >
ing.
Regards,
Stefan
Index: subversion/tests/cmdline/resolve_tests.py
===
--- subversion/tests/cmdline/resolve_tests.py (revision 1758150)
+++ subversion/tests/cmdline/resolve_tests.py (working copy)
@@ -642,19 +642,19 @@
# Test '
On 8/28/2016 20:23, Daniel Shahaf wrote:
> Stefan wrote on Sun, Aug 28, 2016 at 13:31:39 +0200:
>> The regression test was tested against 1.9.4, 1.9.x and trunk r1743999.
>>
>> I also tried to run the test against 1.8.16 but there it fails (didn't
>> investigate in
On 8/28/2016 13:31, Stefan wrote:
> Hi,
>
> attached is a new version of the patch which adds a regression test (the
> actual patch/fix was left unchanged).
> The regression test was tested against 1.9.4, 1.9.x and trunk r1743999.
>
> I also tried to run the test against 1.8.
of
svn_wc_conflict_choose_mine_full
* subversion/tests/cmdline/resolve_tests.py
(automatic_binary_conflict_resolution): add new regression test
Suggested by: stsp
]]]
Regards,
Stefan
Index: subversion/libsvn_wc/conflicts.c
On 8/28/2016 03:53, Daniel Shahaf wrote:
> Stefan wrote on Sun, Aug 28, 2016 at 00:06:19 +0200:
>> START: resolve_tests.py
>> W: Unexpected output
>> W: EXPECTED STDOUT (unordered):
>> W: | Resolved conflicted state of 's'
>> W: | Resolved conflicted state of 'v'
On 8/16/2016 17:54, Stefan Hett wrote:
> Hi,
>
> attached is a different approach to resolve the conflict resolution
> issue based on stsp's suggestion.
> The patch was tested against 1.9.x as well as trunk without triggering
> any test failures.
> It was also tested manual
NoneType' object has no attribute 'readlines'
[1] = https://issues.apache.org/jira/browse/SVN-4647
[2] = http://svn.haxx.se/dev/archive-2016-08/0020.shtml
Regards,
Stefan
Index: subversion/tests/cmdline/resolve_tests.py
===
--- subve
(and your other two commits) be something which should be
considered to backport to 1.9 (and maybe even 1.8)? As far as I was
following the history of this, it sounds like a reasonable improvement
worth for a backport, no?
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
ds without producing any file conflicts:
- "svn merge [URL]" or
- "svn merge [URL]@X+1"
[1] https://issues.apache.org/jira/browse/SVN-4649
--
Regards,
Stefan Hett
seems to require more work
due to the test failures the previous patch triggered.
--
Regards,
Stefan Hett
Index: subversion/libsvn_wc/conflicts.c
===
--- subversion/libsvn_wc/conflicts.c(revision 1755499)
+++ subversion
rds,
Stefan Hett, Developer/Administrator
EGOSOFT GmbH, Heidestrasse 4, 52146 Würselen, Germany
Tel: +49 2405 4239970, www.egosoft.com
Geschäftsführer: Bernd Lehahn, Handelsregister Aachen HRB 13473
.de:8090/browse/MAXSVN
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On 8/8/2016 14:53, Stefan Hett wrote:
> On 8/8/2016 12:22 PM, Ivan Zhakov wrote:
>
>> On 7 August 2016 at 23:14, Stefan <luke1...@posteo.de> wrote:
>>
>> Btw what are the problems with approach to disable watson reports on
>> abort(), except backporting? I me
On 8/8/2016 12:22 PM, Ivan Zhakov wrote:
On 7 August 2016 at 23:14, Stefan <luke1...@posteo.de> wrote:
On 8/7/2016 21:16, Ivan Zhakov wrote:
On 7 August 2016 at 21:27, Stefan Sperling <s...@elego.de> wrote:
On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
On Sun,
On 8/7/2016 21:16, Ivan Zhakov wrote:
> On 7 August 2016 at 21:27, Stefan Sperling <s...@elego.de> wrote:
>> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>>> Hi,
>>>>
&
On 8/7/2016 20:27, Stefan Sperling wrote:
> On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
>> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
>>> Hi,
>>>
>>> the attached patch is the outcome of talking with jcorval on IRC about a
>
On Sun, Aug 07, 2016 at 08:23:58PM +0200, Stefan Sperling wrote:
> On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
> > Hi,
> >
> > the attached patch is the outcome of talking with jcorval on IRC about a
> > test suite issue on Windows (release builds) in SVN 1.
On Sun, Aug 07, 2016 at 02:08:35PM +0200, Stefan wrote:
> Hi,
>
> the attached patch is the outcome of talking with jcorval on IRC about a
> test suite issue on Windows (release builds) in SVN 1.8. It resolves the
> fact that the tests will be interrupted on Windows by a Windo
suite
]]]
Regards,
Stefan
Index: subversion/libsvn_subr/cmdline.c
===
--- subversion/libsvn_subr/cmdline.c (revision 1755433)
+++ subversion/libsvn_subr/cmdline.c (working copy)
@@ -162,6 +162,10 @@
{
/* In release
On 7/26/2016 17:58, Stefan Hett wrote:
> On 7/26/2016 5:46 PM, Stefan Hett wrote:
>> Hi,
>>
>> based on the talk on IRC with stsp and Bert I'd like to propose the
>> following patch which would resolve an issue in TSVN when selecting
>> to prefer the local version
On 7/31/2016 14:17, Stefan wrote:
> Hi,
>
> the current test code causes two test failures on my machine (Windows,
> python 64-bit, drives G-J HDDs, drive K dvd drive - tested with SVN
> 1.9.4 and trunk).
> The issue seems to be that the fallback detection code incorrectly
> c
mdline/update_tests.py
(update_wc_on_windows_drive): the same
]]]
[1] http://www.luke1410.de:8090/browse/MAXSVN-65
[2] http://python.net/crew/theller/ctypes/
Regards,
Stefan
Index: subversion/tests/cmdline/checkout_te
On Wed, Jul 27, 2016 at 08:02:07AM +, Thomsen, Allan A B wrote:
> Hi,
>
> I encountered this issue on 1.9.3 and upgraded to 1.9.4 - no difference
>
> If I do a cleanup I get:
> Quote
> Subversion reported the following
> (you can copy the content of this dialog
> to the clipboard using
On Wed, Jul 27, 2016 at 09:24:08AM +, Thomsen, Allan A B wrote:
> Is the general recommendation against using network drives all together or
> just when there is a risk of multiple instance access?
Altogether. Store working copies on local disk (or something which
*really* looks like a local
On Wed, Jul 27, 2016 at 08:02:07AM +, Thomsen, Allan A B wrote:
> The place the files are stored is on a network drive.
We generally recommend against storing working copies on network
drives because sqlite has problems with this: http://sqlite.org/faq.html#q5
On 7/26/2016 11:25, Stefan Hett wrote:
> Hi,
>
> On 7/26/2016 1:01 AM, Stefan wrote:
>> Hi,
>>
>> the attached patch adds detction of the bin-directory location inside
>> httpd, which is the default location for apr binaries, if apr is
>> integrated in
On 7/26/2016 5:46 PM, Stefan Hett wrote:
Hi,
based on the talk on IRC with stsp and Bert I'd like to propose the
following patch which would resolve an issue in TSVN when selecting to
prefer the local version of a binary file in conflict (see: "code
location related to investigate pote
variable
and set it in the two cases where we
simply accept the current local
file to
resolve the conflict.
]]]
--
Regards,
Stefan Hett
Index: subversion/libsvn_wc/c
Hi,
On 7/26/2016 1:01 AM, Stefan wrote:
Hi,
the attached patch adds detction of the bin-directory location inside
httpd, which is the default location for apr binaries, if apr is
integrated in httpd/srclib rather than a stand alone project.
The patch would apply to trunk and 1.9.
I'm taking
Hi,
the attached patch adds detction of the bin-directory location inside
httpd, which is the default location for apr binaries, if apr is
integrated in httpd/srclib rather than a stand alone project.
The patch would apply to trunk and 1.9.
Regards,
Stefan
Index: build/generator
system cannot find the path specified:
'[...]\\dependencies\\httpd\\srclib\\apr\\bin/*.*'
The attached patch adds a check to produce a better readable error instead:
ERROR: no apr bin folder detected.
Make sure to have apr built prior to generating the SVN project.
Reg
add a 1.8 backport branch and nominate it for
backporting to the 1.8-branch.
Regards,
Stefan
Index: subversion/tests/libsvn_wc/wc-queries-test.c
===
--- subversion/tests/libsvn_wc/wc-queries-test.c (revision 1746366)
+++ subversion/te
On 7/17/2016 22:09, Branko Čibej wrote:
> On 17.07.2016 20:53, Stefan wrote:
>> Hi Daniel,
>>> Stefan wrote on Thu, Jul 14, 2016 at 00:14:31 +0200:
>>>> Note that SVN 1.7 is EOL and therefore isn't supported anymore.
>>> Maybe add this to the 1.7.x STAT
Hi Daniel,
> Stefan wrote on Thu, Jul 14, 2016 at 00:14:31 +0200:
>> Note that SVN 1.7 is EOL and therefore isn't supported anymore.
> Maybe add this to the 1.7.x STATUS file? The "unsupported" label means
> we don't promise to investigate or fix bugs, but you clearly did
ves the compile error (patch was suggested by
rhuijben).
Full details: http://www.luke1410.de:8090/browse/MAXSVN-55
Regards,
Stefan
--- G:\Projekte\MaxSVN\1.7.22\subversion\libsvn_subr\sqlite.c Wed Jul 13 23:25:58 2016
+++ G:\Projekte\MaxSVN\patches\svn\1.7.22\sqlite.c Tue Jul 12 01:22:51 2
On 6/30/2016 22:26, Stefan Sperling wrote:
> On Thu, Jun 30, 2016 at 11:21:30AM +, Ioannis Kappas wrote:
>> Hello,
>>
>> Can you please kindly consider picking up the fix with revision 1683266
>> (http://svn.apache.org/viewvc?view=revision=1683266) in the
>&g
On 6/27/2016 1:57 PM, Greg Stein wrote:
On Mon, Jun 27, 2016 at 6:54 AM, Greg Stein <gst...@gmail.com
<mailto:gst...@gmail.com>> wrote:
On Sun, Jun 26, 2016 at 7:49 PM, Stefan <luke1...@posteo.de
<mailto:luke1...@posteo.de>> wrote:
>...
On 6/27/2016 03:43, Daniel Shahaf wrote:
> Stefan wrote on Mon, Jun 27, 2016 at 02:49:51 +0200:
>>> On Sun, Jun 26, 2016 at 09:26:27PM +0200, Stefan wrote:
>>>> I'm just wondering why the backward compatibility for 1.9.0 (and 1.8.0)
>>>> doesn't state 1
On 6/27/2016 01:43, James McCoy wrote:
> On Sun, Jun 26, 2016 at 09:26:27PM +0200, Stefan wrote:
>> I'm just wondering why the backward compatibility for 1.9.0 (and 1.8.0)
>> doesn't state 100% here [1].
>>
>> Checking out the details on 1.9.0 [2] and there the d
.9.0/d6980/abi_compat_report.html#Added
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
On 6/23/2016 00:33, Johan Corveleyn wrote:
> On Wed, Jun 22, 2016 at 2:07 PM, Stefan Hett <ste...@egosoft.com> wrote:
>> On 6/22/2016 1:38 AM, Mark Phippard wrote:
>>>
>>>> On Jun 21, 2016, at 7:20 PM, Johan Corveleyn <jcor...@gmail.com> wrote:
>
icable to the current
supported version.
--
Regards,
Stefan Hett
On Wed, Jun 22, 2016 at 01:20:21AM +0200, Johan Corveleyn wrote:
> 1) Move anything only relevant to old releases (anything < 1.9 or <
> 1.8 (?)) to a separate page (faq_old.html or something -- linked from
> the main faq with a link somewhere at the top "Questions about older
> releases").
Or
On Tue, Jun 21, 2016 at 12:51:42PM +0200, Branko Čibej wrote:
> On 21.06.2016 09:16, s...@apache.org wrote:
> > Author: stsp
> > Date: Tue Jun 21 07:16:34 2016
> > New Revision: 1749456
> >
> > URL: http://svn.apache.org/viewvc?rev=1749456=rev
> > Log:
> > * subversion/trunk: Add "gmock-fused" to
On Mon, Jun 20, 2016 at 08:34:24AM +0200, Stefan Fuhrmann wrote:
> Can you say what the main limitations are and whether you
> plan to remove them? My guess would be: files only, one
> move per file & conflict resolution cycle, no cyclic renames.
>
> -- Stefan^2.
I expect
On 13.06.2016 16:10, Stefan Sperling wrote:
On Mon, Jun 13, 2016 at 01:51:49PM -, s...@apache.org wrote:
Author: stsp
Date: Mon Jun 13 13:51:49 2016
New Revision: 1748236
URL: http://svn.apache.org/viewvc?rev=1748236=rev
Log:
When merging an incoming file move, record this move
Re: new svn conflict resolver status update
> >
> > On Mon, Jun 13, 2016 at 12:50 PM, Stefan Sperling <s...@elego.de> wrote:
> > > On Mon, Jun 13, 2016 at 12:05:27AM +0200, Johan Corveleyn wrote:
> > >> To be honest, being able to use the python test framew
e into the code
to make things consistent, and send patches. If you cannot contribute code,
then you could instead compile a list of concrete suggestions about how to
make things consistent, and post it here.
Thanks,
Stefan
On Mon, Jun 13, 2016 at 01:51:49PM -, s...@apache.org wrote:
> Author: stsp
> Date: Mon Jun 13 13:51:49 2016
> New Revision: 1748236
>
> URL: http://svn.apache.org/viewvc?rev=1748236=rev
> Log:
> When merging an incoming file move, record this move in the working copy.
>
> This makes merged
I have been regularly working on the new conflict resolver since January.
This is a status update to present the results so far, and what remains
to be done before we can release this.
The code is on trunk, and not on a branch. We could still disable it
without much effort. However, at this point
On 6/1/2016 1:57 PM, Stefan Sperling wrote:
On Wed, Jun 01, 2016 at 12:37:08PM +0200, Stefan Hett wrote:
So with the change we are
actually resolving problems for more standard compliant and also for older
browsers working on that page.
Do you have any evidence of browsers not accepting
On Wed, Jun 01, 2016 at 12:37:08PM +0200, Stefan Hett wrote:
> So with the change we are
> actually resolving problems for more standard compliant and also for older
> browsers working on that page.
Do you have any evidence of browsers not accepting that link?
Based on what Daniel Stenb
On 6/1/2016 9:47 AM, Stefan Sperling wrote:
On Mon, May 16, 2016 at 03:44:58PM +0200, Stefan wrote:
(issues): rename section id so it doesn't start with a number
Is breaking section links like the one below worth it?
It's not going to be a big problem for people to locate the right
section
On Mon, May 16, 2016 at 03:44:58PM +0200, Stefan wrote:
> (issues): rename section id so it doesn't start with a number
Is breaking section links like the one below worth it?
It's not going to be a big problem for people to locate the right
section on the page even if this link chan
On 5/16/2016 15:44, Stefan wrote:
> Hi,
>
> the attached patch fixes some remaining XHTML validation issues in the
> release notes.
>
> This is expected to be the last patch for this run. The remaining errors
> seem to be related to the use of HTML5-specific features (error
On 5/31/2016 5:37 PM, Evgeny Kotkov wrote:
Stefan Hett <luke1...@apache.org> writes:
New Revision: 1746281
URL: http://svn.apache.org/viewvc?rev=1746281=rev
Log:
* README
Correct the svnbook sources URL (now hosted on SourceForge).
Obvious fix.
Patch by: Pavel Lyalyakin <pav
://svn.apache.org/repos/asf/subversion/trunk/README
Thanks for the patch. Applied to trunk in r1746277 and backported to
1.8+1.9.
--
Regards,
Stefan Hett
lists. Replying to your own thread
on the users@ list and mentioning the lack of responses should suffice.
Even if you do so a few times, it won't disturb anyone.
I'll try to find your post on users@ and reply there.
Thanks,
Stefan
On Thu, May 26, 2016 at 11:15:11PM +0300, Pavel Lyalyakin wrote:
> Hello,
>
> I'm reading through the nightly SVNBook 1.8 and make more or less
> necessary changes to complete it and begin the work on SVNBook 1.9.
> I've just noticed that the output of `svn help` is slightly different
> in SVN
On Thu, May 26, 2016 at 02:51:23AM +0200, Stefan wrote:
> On 5/25/2016 18:11, astie...@apache.org wrote:
> > Author: astieger
> > Date: Wed May 25 16:11:01 2016
> > New Revision: 1745515
> >
> > URL: http://svn.apache.org/viewvc?rev=1745515=rev
> > Log:
>
svn/src_releases/$SERF.tar.bz2
> +$HTTP_FETCH https://archive.apache.org/dist/serf/$SERF.tar.bz2
> cd $BASEDIR
>
> bzip2 -dc $TEMPDIR/$SERF.tar.bz2 | tar -xf -
Nominated for backport to 1.8 and 1.9.
Regards,
Stefan
smime.p7s
Description: S/MIME Cryptographic Signature
Hi Pavel,
On 5/24/2016 13:31, Pavel Lyalyakin wrote:
> Hello Stefan,
>
> On Mon, May 23, 2016 at 8:34 PM, Stefan <luke1...@posteo.de> wrote:
>> Hi Pavel,
>>
>> Thanks for the feedback.
>> Can't say I disagree with your statement that emphasizing on one
>&g
Hi Pavel,
> Hello,
>
> On Fri, May 20, 2016 at 10:50 PM, Stefan <luke1...@posteo.de> wrote:
>> On 5/15/2016 02:00, Stefan wrote:
>>> Hi,
>>>
>>>
>>> following patch adds a new entry to the FAQ's trouble shooting
>>> section, docu
On 5/16/2016 16:18, Branko Čibej wrote:
> On 16.05.2016 15:07, Stefan wrote:
>> On 5/16/2016 14:29, Branko Čibej wrote:
>>> On 16.05.2016 13:24, Stefan wrote:
>>>> On 5/16/2016 13:14, Ivan Zhakov wrote:
>>>>> On 16 May 2016 at 13:43, Stefan <luke
On 5/15/2016 02:00, Stefan wrote:
> Hi,
>
>
> following patch adds a new entry to the FAQ's trouble shooting
> section, documenting the known problem with large headers, exceeding
> Apache httpd's LimitRequestFieldSize setting.
>
> [[[
> Document known issue about l
On 13.05.2016 19:51, Evgeny Kotkov wrote:
Stefan Fuhrmann<stef...@apache.org> writes:
The new condition looks fairly suspicious.
Sure, but no worse than before.
I think it's actually worse than before, as now it looks like this function
was updated for Python 3, whereas in fact it ge
As it turns out, using codecs.open() would only work in Python 3.
In Python 2, imp.load_module() requires a plain file parameter
and anything wrapped etc. would not work.
-- Stefan^2.
801 - 900 of 4519 matches
Mail list logo
