On Fri, May 2, 2014 at 2:18 AM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> Verified:
>
> (fsfs, bdb) x (local, svnserve, neon, serf)
>
Copy'n'pasto. Correction:
(fsfs, bdb) x (local, svnserve, serf)
> -- Stefan^2.
>
On Wed, Apr 30, 2014 at 8:00 PM, Ben Reser wrote:
> The 1.7.17 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on May 7th so
> please
> try and
On Wed, Apr 30, 2014 at 8:21 PM, Ben Reser wrote:
> The 1.8.9 release artifacts are now available for testing/signing.
> Please get the tarballs from
> https://dist.apache.org/repos/dist/dev/subversion
> and add your signatures there. I plan to try and release on May 7th
> so please try and ge
Daniel Shahaf wrote on Thu, May 01, 2014 at 22:52:06 +:
> Philip Martin wrote on Thu, May 01, 2014 at 19:04:04 +0100:
> > Philip Martin writes:
> >
> > > svn_diff_conflict_display_modified_latest is similar to the output of
> > > GNU diff3 which is probably why it was chosen. Changing it mig
Philip Martin wrote on Thu, May 01, 2014 at 19:04:04 +0100:
> Philip Martin writes:
>
> > svn_diff_conflict_display_modified_latest is similar to the output of
> > GNU diff3 which is probably why it was chosen. Changing it might cause
> > problems for tools that parse the output, but one option
Philip Martin writes:
> An error in my testsuite change. This passes all the tests with the
> 3-way output:
>
> Index: subversion/libsvn_wc/merge.c
> ===
> --- subversion/libsvn_wc/merge.c (revision 1591407)
> +++ subversion/li
Philip Martin writes:
> svn_diff_conflict_display_modified_latest is similar to the output of
> GNU diff3 which is probably why it was chosen. Changing it might cause
> problems for tools that parse the output, but one option for anyone
> affected would be to use GNU diff3 with --diff3-cmd.
We
Philip Martin writes:
> Philip Martin writes:
>
>> Daniel Shahaf writes:
>>
>>> --- subversion/libsvn_wc/merge.c2011-08-06 19:15:44.0 +0400
>>> +++ subversion/libsvn_wc/merge.c2011-09-07 21:47:19.0 +0400
>>> @@ -413,7 +413,7 @@
>>>
Philip Martin writes:
> Daniel Shahaf writes:
>
>> --- subversion/libsvn_wc/merge.c 2011-08-06 19:15:44.0 +0400
>> +++ subversion/libsvn_wc/merge.c 2011-09-07 21:47:19.0 +0400
>> @@ -413,7 +413,7 @@
>>target_marker,
>>
Thanks for the detailed response,
Bert
-Original Message-
From: "Julian Foad"
Sent: 1-5-2014 15:12
To: "Bert Huijben"
Cc: "dev@subversion.apache.org"
Subject: Re: svn commit:
r1591301-/subversion/trunk/subversion/libsvn_client/mergeinfo.c
Bert Huijben wrote:
> Are you sure that it
Summary:
+1 to release
Platform:
Linux (Debian/wheezy) 64-bit
Tested:
(local, svn, svn/sasl, serf, serf/v1) x (fsfs, fsfs/pack/shard, bdb)
swig-pl, swig-py, swig-rb, ctypes-python
javahl x (fsfs, bdb)
Results:
All tests successful
Local dependencies:
apache2-threaded-dev : 2.
Bert Huijben wrote:
> Are you sure that it doesn't return the mergeinfo as it applies to the
> target, even if it has found that information by looking at the parent?
> (That is what I tried to say)
Hi, Bert. Note the comment on the code I changed:
/* Get the TARGET_WCPATH's explicit mergeinfo.
Are you sure that it doesn't return the mergeinfo as it applies to the target,
even if it has found that information by looking at the parent? (That is what I
tried to say)
I'm not familiar enough with this code to really review it from just the code,
but this eliding code is quite sensitive a
Bert Huijben wrote:
> This might make us add svn:mergeinfo on nodes that didn't have this property
> before eliding, while the old code tried to avoid that by checking to see if
> the value was inherited from an ancestor.
Hi Bert. I can't quite parse your sentence unambiguously, but I believe this
1 maj 2014 kl. 08.13 skrev Dongsheng Song:
_("The repository trunk version is %"PRId64".")
Will translate to:
_("The repository trunk version is %lld.") // ILP32
_("The repository trunk version is %I64d.") // MSVC
_("The repository trunk version is %ld.") // LP64
No, gettext recognises stand
15 matches
Mail list logo
