Translation status report for trunk@r1241345
lang trans untrans fuzzy obs
--
de2081 192 308 271 UUooo
es2007 266 385 405 ++UUU~
fr2271 2
On Mon, Feb 06, 2012 at 05:34:48PM -0800, Daniel Shahaf wrote:
> Trent Nelson wrote on Mon, Feb 06, 2012 at 15:22:21 -0500:
> > On Mon, Feb 06, 2012 at 11:39:13AM -0800, Hyrum K Wright wrote:
> > > On Mon, Feb 6, 2012 at 1:25 PM, Blair Zajac wrote:
> > > > With a fsfs corruption bug found and fixe
Trent Nelson wrote on Mon, Feb 06, 2012 at 15:22:21 -0500:
> On Mon, Feb 06, 2012 at 11:39:13AM -0800, Hyrum K Wright wrote:
> > On Mon, Feb 6, 2012 at 1:25 PM, Blair Zajac wrote:
> > > With a fsfs corruption bug found and fixed this week [1], should we cut a
> > > 1.6.18? 1.6.17 was tagged 8 mon
On Tue, Feb 7, 2012 at 12:49 AM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> I actually don't see anything either in the Apache error log (except
>> the child process starting up etc). Or should I look somewhere else?
>
> The error log is the right place.
>
>> Just to add some more info:
Paul Burba wrote on Mon, Feb 06, 2012 at 18:15:11 -0500:
> Hi All,
>
> There has long been a desire for Subversion to support some form of
> inherited properties. Recently, while discussing a potential solution
> for server dictated configurations (see
> http://svn.haxx.se/dev/archive-2012-01/003
Johan Corveleyn writes:
> I actually don't see anything either in the Apache error log (except
> the child process starting up etc). Or should I look somewhere else?
The error log is the right place.
> Just to add some more info: I can't reproduce with mod_dav_svn from
> trunk@1237720 or trunk@
In most data storage mechanisms for the repository, inheritable
properties are a performance killer. Bill Tutt advised us against
inheritable properties years ago for exactly this reason. It is one of
the main reasons that we never implemented them. Good data modeling
for path-based inheritance is
Well, sure. It will still be correct because our Ev2-aware libraries
will not use Ev1 APIs, and (thus) never have shims inserted. But I
think that "third-party" helps to clarify who we're talking about:
developers/products that are not part of the core svn releases. In any
case, we're just talking
On Tue, Feb 7, 2012 at 12:08 AM, Philip Martin
wrote:
> Daniel Shahaf writes:
>
>> Does the test trigger the error message
>> 680 ap_log_rerror(APLOG_MARK, APLOG_ERR, serr->apr_err,
>> 681 resource->info->r,
>> 682 "Can't
I get your distinction between "clients that use the native Ev2 API",
"clients that use the Ev1 API in Ev2-aware libraries", and "clients that
use the Ev1 API in Ev2-oblivious libraries".
But I think striking the word(s) "third-party" from your third paragraph
will not affect its correctness.
Gre
Hi All,
There has long been a desire for Subversion to support some form of
inherited properties. Recently, while discussing a potential solution
for server dictated configurations (see
http://svn.haxx.se/dev/archive-2012-01/0032.shtml), the idea of using
inheritable properties as an alternative
On Wed, Feb 1, 2012 at 7:38 AM, Julian Foad wrote:
> Hi Paul. Thanks for indulging my enquiries.
>
> Paul Burba wrote:
>
>> Julian Foad wrote:
>>> Overriding is done by setting a new value for the inheritable
>>> property svn:i:ignore, like this:
>>>
>>> /subversion svn:i:ignore
Daniel Shahaf writes:
> Does the test trigger the error message
> 680 ap_log_rerror(APLOG_MARK, APLOG_ERR, serr->apr_err,
> 681 resource->info->r,
> 682 "Can't fetch or compute MD5 checksum of
> '%s': "
> 683
On Mon, Feb 6, 2012 at 17:39, Daniel Shahaf wrote:
>...
> 1. Third-parties who use Ev1 interface would lose the integrity check.
>
> 2. Subversion 1.7 uses, and will use, Ev1 interfaces.
>
> Therefore:
>
> 3. Subversion 1.7 would lose the integrity check.
>
> Correct?
Nope. 'svn' is not considere
Greg Stein wrote on Mon, Feb 06, 2012 at 17:26:59 -0500:
> On Mon, Feb 6, 2012 at 17:13, Daniel Shahaf wrote:
> > Greg Stein wrote on Mon, Feb 06, 2012 at 17:06:54 -0500:
> >> On Mon, Feb 6, 2012 at 15:55, Daniel Shahaf wrote:
> >> > Greg Stein wrote on Mon, Feb 06, 2012 at 15:49:10 -0500:
> >> >
On Mon, Feb 6, 2012 at 17:13, Daniel Shahaf wrote:
> Greg Stein wrote on Mon, Feb 06, 2012 at 17:06:54 -0500:
>> On Mon, Feb 6, 2012 at 15:55, Daniel Shahaf wrote:
>> > Greg Stein wrote on Mon, Feb 06, 2012 at 15:49:10 -0500:
>> >> On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato
>> >> wrote:
>>
On Tue, Feb 07, 2012 at 06:26:54AM +0900, Hiroaki Nakamura wrote:
> 2012/2/6 Stefan Sperling :
> > 2) Do something else that effects repositories, too, and provide
> > a clean upgrade path for everyone (servers and clients).
> > AFAIK nobody has made a suggestion as to what could be done her
On Mon, Feb 6, 2012 at 16:02, C. Michael Pilato wrote:
> On 02/06/2012 03:54 PM, Hyrum K Wright wrote:
>>...
>> And I'll note that the base checksum check is superfluous, as the
>> resulting contents check is still valid and being performed.
>
> That alone doesn't make the check superfluous. To m
Greg Stein wrote on Mon, Feb 06, 2012 at 17:06:54 -0500:
> On Mon, Feb 6, 2012 at 15:55, Daniel Shahaf wrote:
> > Greg Stein wrote on Mon, Feb 06, 2012 at 15:49:10 -0500:
> >> On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato
> >> wrote:
> >> > On 02/06/2012 03:41 PM, Greg Stein wrote:
> >> >> Tha
On Mon, Feb 6, 2012 at 15:55, Daniel Shahaf wrote:
> Greg Stein wrote on Mon, Feb 06, 2012 at 15:49:10 -0500:
>> On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato wrote:
>> > On 02/06/2012 03:41 PM, Greg Stein wrote:
>> >> That is certainly an easier approach. "You use the old interface?
>> >> Fine
On 06.02.2012 22:26, Hiroaki Nakamura wrote:
> The Unicode Standard says canonical equivalent sequences should be
> interpreted the same way.
> * 1.1 Canonical and Compatibility Equivalence
> http://unicode.org/reports/tr15/#Canonical_Equivalence
> * 2.12 Equivalent Sequences and Normalization
>
Johan Corveleyn wrote on Mon, Feb 06, 2012 at 22:48:21 +0100:
> On Mon, Feb 6, 2012 at 10:21 PM, Johan Corveleyn wrote:
> > On Mon, Feb 6, 2012 at 9:16 PM, Daniel Shahaf wrote:
> >> Hyrum K Wright wrote on Mon, Feb 06, 2012 at 11:44:06 -0600:
> >>> The question I have, which is more 1.7.3-centric
On Mon, Feb 6, 2012 at 10:21 PM, Johan Corveleyn wrote:
> On Mon, Feb 6, 2012 at 9:16 PM, Daniel Shahaf wrote:
>> Hyrum K Wright wrote on Mon, Feb 06, 2012 at 11:44:06 -0600:
>>> The question I have, which is more 1.7.3-centric, is "what changed on
>>> the 1.7.x branch to start this happening?"
2012/2/6 Stefan Sperling :
> On Mon, Feb 06, 2012 at 02:28:40PM +0100, Branko Čibej wrote:
>> On 06.02.2012 14:10, Hiroaki Nakamura wrote:
>> > Hi, all.
>> >
>> > It seems there is no further discussion.
>> >
>> > I think the conclusion for the short term solution is:
>> > We convert unnormalized p
On Mon, Feb 6, 2012 at 9:16 PM, Daniel Shahaf wrote:
> Hyrum K Wright wrote on Mon, Feb 06, 2012 at 11:44:06 -0600:
>> The question I have, which is more 1.7.3-centric, is "what changed on
>> the 1.7.x branch to start this happening?" Perhaps answering that
>> will help us know what needs to be d
On 02/06/2012 03:54 PM, Hyrum K Wright wrote:
> On Mon, Feb 6, 2012 at 2:49 PM, Greg Stein wrote:
>> On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato wrote:
>>> On 02/06/2012 03:41 PM, Greg Stein wrote:
That is certainly an easier approach. "You use the old interface?
Fine. You won't get
Greg Stein wrote on Mon, Feb 06, 2012 at 15:49:10 -0500:
> On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato wrote:
> > On 02/06/2012 03:41 PM, Greg Stein wrote:
> >> That is certainly an easier approach. "You use the old interface?
> >> Fine. You won't get base checksum verification cuz we'll alway
On 02/06/2012 03:49 PM, Greg Stein wrote:
> Ev2 only has checksums for the resulting content. It uses
> path/revision to specify the target of the text change.
Ev1 also uses path/revision to specify the target of the text change. I
wasn't aware that Ev2 was dropping an existing safeguard, though,
On Mon, Feb 6, 2012 at 2:49 PM, Greg Stein wrote:
> On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato wrote:
>> On 02/06/2012 03:41 PM, Greg Stein wrote:
>>> That is certainly an easier approach. "You use the old interface?
>>> Fine. You won't get base checksum verification cuz we'll always pass
>>
On Mon, Feb 6, 2012 at 15:44, C. Michael Pilato wrote:
> On 02/06/2012 03:41 PM, Greg Stein wrote:
>> That is certainly an easier approach. "You use the old interface?
>> Fine. You won't get base checksum verification cuz we'll always pass
>> NULL." ... that seems like a fine position to take.
>
>
On Mon, Feb 6, 2012 at 15:22, Trent Nelson wrote:
> On Mon, Feb 06, 2012 at 11:39:13AM -0800, Hyrum K Wright wrote:
>> On Mon, Feb 6, 2012 at 1:25 PM, Blair Zajac wrote:
>> > With a fsfs corruption bug found and fixed this week [1], should we cut a
>> > 1.6.18? 1.6.17 was tagged 8 months ago. I
On 02/06/2012 03:41 PM, Greg Stein wrote:
> That is certainly an easier approach. "You use the old interface?
> Fine. You won't get base checksum verification cuz we'll always pass
> NULL." ... that seems like a fine position to take.
This might be a fine position to take for some third-party cons
On Mon, Feb 6, 2012 at 15:41, C. Michael Pilato wrote:
> On 02/06/2012 03:21 PM, Hyrum K Wright wrote:
>...
>> Receivers (such as ours) are making unreasonable assumptions, in my
>> opinion. The docs for apply_textdelta() read thusly:
It is hand-wavey voodoo, but that is how it has been built. T
On 02/06/2012 03:21 PM, Hyrum K Wright wrote:
> On Mon, Feb 6, 2012 at 1:26 PM, Greg Stein wrote:
>> On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright
>> wrote:
>>> ...
Yeah, sounds like we're in a tough spot here. The checksums in Ev1 exist
only as sanity checks -- they definitely are NOT
On Mon, Feb 6, 2012 at 15:29, Hyrum K Wright wrote:
> On Mon, Feb 6, 2012 at 2:21 PM, Hyrum K Wright
> wrote:
>> On Mon, Feb 6, 2012 at 1:26 PM, Greg Stein wrote:
>>> On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright
>>> wrote:
...
> Yeah, sounds like we're in a tough spot here. The checks
On Mon, Feb 6, 2012 at 15:18, Hyrum K Wright wrote:
> On Mon, Feb 6, 2012 at 2:03 PM, Greg Stein wrote:
>...
>> If the shim sends a delta against the empty-stream, then how can the
>> Ev1 receiver properly apply that? Won't the receiver use some selected
>> base contents? ie. NOT the empty stream
On Mon, Feb 6, 2012 at 2:21 PM, Hyrum K Wright
wrote:
> On Mon, Feb 6, 2012 at 1:26 PM, Greg Stein wrote:
>> On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright
>> wrote:
>>>...
Yeah, sounds like we're in a tough spot here. The checksums in Ev1 exist
only as sanity checks -- they definitely
On Mon, Feb 06, 2012 at 11:39:13AM -0800, Hyrum K Wright wrote:
> On Mon, Feb 6, 2012 at 1:25 PM, Blair Zajac wrote:
> > With a fsfs corruption bug found and fixed this week [1], should we cut a
> > 1.6.18? 1.6.17 was tagged 8 months ago. If we don't cut a new release,
> > then we should probabl
On Mon, Feb 6, 2012 at 1:26 PM, Greg Stein wrote:
> On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright
> wrote:
>>...
>>> Yeah, sounds like we're in a tough spot here. The checksums in Ev1 exist
>>> only as sanity checks -- they definitely are NOT the primary selection
>>> mechanism for the editor im
On Mon, Feb 6, 2012 at 2:03 PM, Greg Stein wrote:
> On Mon, Feb 6, 2012 at 14:32, Hyrum K Wright
> wrote:
>> On Mon, Feb 6, 2012 at 1:28 PM, Greg Stein wrote:
>>> On Mon, Feb 6, 2012 at 12:48, wrote:
Author: hwright
Date: Mon Feb 6 17:48:36 2012
New Revision: 1241097
Hyrum K Wright wrote on Mon, Feb 06, 2012 at 11:44:06 -0600:
> The question I have, which is more 1.7.3-centric, is "what changed on
> the 1.7.x branch to start this happening?" Perhaps answering that
> will help us know what needs to be done to fix the problem.
>
Philip pointed out on IRC that
On Mon, Feb 6, 2012 at 14:32, Hyrum K Wright wrote:
> On Mon, Feb 6, 2012 at 1:28 PM, Greg Stein wrote:
>> On Mon, Feb 6, 2012 at 12:48, wrote:
>>> Author: hwright
>>> Date: Mon Feb 6 17:48:36 2012
>>> New Revision: 1241097
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1241097&view=rev
>>> Log
On Mon, Feb 6, 2012 at 1:25 PM, Blair Zajac wrote:
> With a fsfs corruption bug found and fixed this week [1], should we cut a
> 1.6.18? 1.6.17 was tagged 8 months ago. If we don't cut a new release,
> then we should probably let downstream distributions know about the issue so
> they can patch
Bojan Smojver wrote on Mon, Feb 06, 2012 at 09:25:59 +1100:
> On Sun, 2012-02-05 at 22:44 +0200, Daniel Shahaf wrote:
> > > > It looks like this was fixed in APR in December 10, 2010 for unix
> > platforms:
> > > >
> > > > http://svn.apache.org/viewvc?view=revision&revision=r100
>
> If Mlade
On Mon, Feb 6, 2012 at 1:28 PM, Greg Stein wrote:
> On Mon, Feb 6, 2012 at 12:48, wrote:
>> Author: hwright
>> Date: Mon Feb 6 17:48:36 2012
>> New Revision: 1241097
>>
>> URL: http://svn.apache.org/viewvc?rev=1241097&view=rev
>> Log:
>> Ev2 shims: Truthfully report our base checksum as being t
On Mon, Feb 6, 2012 at 12:48, wrote:
> Author: hwright
> Date: Mon Feb 6 17:48:36 2012
> New Revision: 1241097
>
> URL: http://svn.apache.org/viewvc?rev=1241097&view=rev
> Log:
> Ev2 shims: Truthfully report our base checksum as being that of the empty
> stream.
>
> Note: This breaks several ass
> -Original Message-
> From: Hyrum K Wright [mailto:hyrum.wri...@wandisco.com]
> Sent: maandag 6 februari 2012 18:59
> To: Philip Martin
> Cc: C. Michael Pilato; Philip Martin; Stephen Butler; Johan Corveleyn;
> Subversion Development
> Subject: Re: 1.7.3 next week-ish?
>
> Serf may hav
> -Original Message-
> From: Philip Martin [mailto:philip.mar...@wandisco.com]
> Sent: maandag 6 februari 2012 18:36
> To: C. Michael Pilato
> Cc: Philip Martin; Stephen Butler; Johan Corveleyn; Hyrum K Wright;
> Subversion Development
> Subject: Re: 1.7.3 next week-ish?
>
> "C. Michael
On Mon, Feb 6, 2012 at 12:49, Hyrum K Wright wrote:
>...
>> Yeah, sounds like we're in a tough spot here. The checksums in Ev1 exist
>> only as sanity checks -- they definitely are NOT the primary selection
>> mechanism for the editor implementation's base text.
Right. This is a key point, and H
With a fsfs corruption bug found and fixed this week [1], should we cut
a 1.6.18? 1.6.17 was tagged 8 months ago. If we don't cut a new
release, then we should probably let downstream distributions know about
the issue so they can patch their builds.
Blair
[1] http://svn.apache.org/viewvc?v
On Mon, Feb 6, 2012 at 11:56 AM, Philip Martin
wrote:
> Hyrum K Wright writes:
>
>> The question I have, which is more 1.7.3-centric, is "what changed on
>> the 1.7.x branch to start this happening?" Perhaps answering that
>> will help us know what needs to be done to fix the problem.
>
> Is it
Hyrum K Wright writes:
> The question I have, which is more 1.7.3-centric, is "what changed on
> the 1.7.x branch to start this happening?" Perhaps answering that
> will help us know what needs to be done to fix the problem.
Is it even on the branch? Perhaps serf changed on the buildbot?
--
On Mon, Feb 6, 2012 at 9:02 AM, C. Michael Pilato wrote:
> On 02/04/2012 01:10 PM, Hyrum K Wright wrote:
>> On Sat, Feb 4, 2012 at 10:59 AM, Julian Foad
>> wrote:
>>> I'm not quite sure I fully follow you at the moment, so I'm not sure if my
>>> reply is on the right track at all, but it's real
On Mon, Feb 6, 2012 at 12:35 PM, Philip Martin
wrote:
> "C. Michael Pilato" writes:
>
>> On 02/06/2012 12:24 PM, C. Michael Pilato wrote:
>>> On 02/06/2012 12:13 PM, Philip Martin wrote:
"C. Michael Pilato" writes:
> Uh... t'ain't right. "Text-delta: true" would appear as the first hea
On Mon, Feb 6, 2012 at 11:35 AM, Philip Martin
wrote:
> "C. Michael Pilato" writes:
>
>> On 02/06/2012 12:24 PM, C. Michael Pilato wrote:
>>> On 02/06/2012 12:13 PM, Philip Martin wrote:
"C. Michael Pilato" writes:
> Uh... t'ain't right. "Text-delta: true" would appear as the first hea
"C. Michael Pilato" writes:
> On 02/06/2012 12:24 PM, C. Michael Pilato wrote:
>> On 02/06/2012 12:13 PM, Philip Martin wrote:
>>> "C. Michael Pilato" writes:
Uh... t'ain't right. "Text-delta: true" would appear as the first header
in
a new header block, hence the reported error
On Mon, Feb 6, 2012 at 11:18 AM, Julian Foad wrote:
>> Hyrum K Wright wrote:
>
>>> What's driving this discussion is this: Up until this point in the
>>> Ev2 shims we've been supplying a NULL base checksum for apply
>>> textdelta, which the receivers have dutifully ignored. However, when
>>> the
On 02/06/2012 12:24 PM, C. Michael Pilato wrote:
> On 02/06/2012 12:13 PM, Philip Martin wrote:
>> "C. Michael Pilato" writes:
>>> Uh... t'ain't right. "Text-delta: true" would appear as the first header in
>>> a new header block, hence the reported error of "Unrecognized record type in
>>> strea
On 02/06/2012 12:13 PM, Philip Martin wrote:
> "C. Michael Pilato" writes:
>> Uh... t'ain't right. "Text-delta: true" would appear as the first header in
>> a new header block, hence the reported error of "Unrecognized record type in
>> stream".
>
> Windows has the same text and properties conte
On Feb 6, 2012, at 17:51 , C. Michael Pilato wrote:
> On 02/06/2012 11:48 AM, Philip Martin wrote:
>> So that's the file D/H/psi, on Linux it looks like:
>>
>> Node-path: trunk/D/H/psi
>> Node-kind: file
>> Node-action: add
>> Prop-delta: true
>> Prop-content-length: 10
>> Text-delta: true
>> Te
> Hyrum K Wright wrote:
>> What's driving this discussion is this: Up until this point in the
>> Ev2 shims we've been supplying a NULL base checksum for apply
>> textdelta, which the receivers have dutifully ignored. However, when
>> the Ev2 shims attempt to be honest about the fact that they ar
"C. Michael Pilato" writes:
> On 02/06/2012 11:48 AM, Philip Martin wrote:
>> So that's the file D/H/psi, on Linux it looks like:
>>
>> Node-path: trunk/D/H/psi
>> Node-kind: file
>> Node-action: add
>> Prop-delta: true
>> Prop-content-length: 10
>> Text-delta: true
>> Text-content-length: 34
>>
On 02/06/2012 11:48 AM, Philip Martin wrote:
> So that's the file D/H/psi, on Linux it looks like:
>
> Node-path: trunk/D/H/psi
> Node-kind: file
> Node-action: add
> Prop-delta: true
> Prop-content-length: 10
> Text-delta: true
> Text-content-length: 34
> Text-content-md5: e81f8f68ba50e749c200cb3
Philip Martin writes:
> Stephen Butler writes:
>
>> Here's the dump file the test is failing to load.
>
> Comparing the failing Windows dump file with the working one on my Linux
> box gives:
>
> $ diff -a svn-test-work/local_tmp-r1-10.dump
> /home/pm/local_tmp-r1-10.dump.txt
> 3c3
> < UUID:
Stephen Butler writes:
> Here's the dump file the test is failing to load.
Comparing the failing Windows dump file with the working one on my Linux
box gives:
$ diff -a svn-test-work/local_tmp-r1-10.dump /home/pm/local_tmp-r1-10.dump.txt
3c3
< UUID: 23ae5c00-308a-48ba-834b-d1e38fd13e10
---
>
Stefan Sperling wrote on Mon, Feb 06, 2012 at 17:12:32 +0100:
> On Mon, Feb 06, 2012 at 05:59:04PM +0200, Daniel Shahaf wrote:
> > This still strips whitespace around ='s in the value:
> > SVNHooksEnv "name = x = y"
> > will result in
> > setenv("name", "x=y", 1)
> > whereas I believe it sh
On Mon, Feb 06, 2012 at 05:59:04PM +0200, Daniel Shahaf wrote:
> This still strips whitespace around ='s in the value:
> SVNHooksEnv "name = x = y"
> will result in
> setenv("name", "x=y", 1)
> whereas I believe it should result in
> setenv("name", "x = y", 1)
> (and, to be honest, I'd
This still strips whitespace around ='s in the value:
SVNHooksEnv "name = x = y"
will result in
setenv("name", "x=y", 1)
whereas I believe it should result in
setenv("name", "x = y", 1)
(and, to be honest, I'd be happy with
setenv("name ", " x = y", 1)
as well).
WDYT? How should i
On 02/04/2012 01:10 PM, Hyrum K Wright wrote:
> On Sat, Feb 4, 2012 at 10:59 AM, Julian Foad
> wrote:
>> I'm not quite sure I fully follow you at the moment, so I'm not sure if my
>> reply is on the right track at all, but it's really sounding like you're up
>> against a mis-match of responsibi
On Mon, Feb 6, 2012 at 8:50 AM, Daniel Shahaf wrote:
> hwri...@apache.org wrote on Mon, Feb 06, 2012 at 14:42:45 -:
>> + checksum = svn_checksum_empty_checksum(svn_checksum_md5, pool);
>> + SVN_TEST_ASSERT(svn_checksum_is_empty_checksum(checksum));
>> +
>
> That doesn't test much -- both fun
hwri...@apache.org wrote on Mon, Feb 06, 2012 at 14:42:45 -:
> + checksum = svn_checksum_empty_checksum(svn_checksum_md5, pool);
> + SVN_TEST_ASSERT(svn_checksum_is_empty_checksum(checksum));
> +
That doesn't test much -- both functions just call
svn_md5__empty_string_digest() which returns
On Feb 6, 2012, at 10:16 , Johan Corveleyn wrote:
> On Mon, Feb 6, 2012 at 10:05 AM, Philip Martin
> wrote:
>> Johan Corveleyn writes:
>>
>>> Doh, you obviously meant that I try it with serf, not with ra_local.
>>> Yes, I can reproduce that: it fails in exactly the same way as the
>>> svn-slik
On Mon, Feb 06, 2012 at 02:28:40PM +0100, Branko Čibej wrote:
> On 06.02.2012 14:10, Hiroaki Nakamura wrote:
> > Hi, all.
> >
> > It seems there is no further discussion.
> >
> > I think the conclusion for the short term solution is:
> > We convert unnormalized paths to NFC normalized paths on clie
On 06.02.2012 14:10, Hiroaki Nakamura wrote:
> Hi, all.
>
> It seems there is no further discussion.
>
> I think the conclusion for the short term solution is:
> We convert unnormalized paths to NFC normalized paths on clients only,
> that is, svn_path_cstring_to_utf8.
>
> It is the same approach a
Hi, all.
It seems there is no further discussion.
I think the conclusion for the short term solution is:
We convert unnormalized paths to NFC normalized paths on clients only,
that is, svn_path_cstring_to_utf8.
It is the same approach as utf8precompose_macosx_2.patch in
http://subversion.tigris.
We could set some informative variables in the hooks' environment, such as:
- $SVN_MAJOR_VERSION, $SVN_MINOR_VERSION, $SVN_PATCH_VERSION
Same as the #define's of the same name.
- $SVN_SERVER_CAPABILITIES
Example: by advertising here that the server has the "validate
revprops are in LF" cap
The below should make the nightly releases bot email its status to
notifications@ too.
- Forwarded message from danie...@apache.org -
> Date: Mon, 06 Feb 2012 11:27:52 -
> From: danie...@apache.org
> To: infrastructure-...@apache.org
> Subject: svn commit: r803998 -
>
> /infras
On Mon, Feb 06, 2012 at 09:00:11AM +0100, Michael Beyer wrote:
> Dear Subversion-Developer-Team,
>
> I'm using subversion on a linux platform and I want to checkout symbolic
> links on a FAT32 partition (USB-Stick). I know, FAT32 doesn't support
> symlinks. But instead of an error message while
Daniel Shahaf writes:
> We're left still with the original problem --- that kwallet
> prompts for unlock even if it doesn't contain the password, but gkeyring
> prompts for unlock regardless of whether it contains the password?
Yes. I can 'fix' gkeyring by moving the unlock prompt into
password
On Mon, Feb 6, 2012 at 10:05 AM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> Doh, you obviously meant that I try it with serf, not with ra_local.
>> Yes, I can reproduce that: it fails in exactly the same way as the
>> svn-slik-w2k3-x64-ra buildbot. Sorry for any confusion.
>>
>> See dav-
Johan Corveleyn writes:
> Doh, you obviously meant that I try it with serf, not with ra_local.
> Yes, I can reproduce that: it fails in exactly the same way as the
> svn-slik-w2k3-x64-ra buildbot. Sorry for any confusion.
>
> See dav-fails.log in attachment.
It's the dump file that fails to load
Dear Subversion-Developer-Team,
I'm using subversion on a linux platform and I want to checkout symbolic links
on a FAT32 partition (USB-Stick). I know, FAT32 doesn't support symlinks. But
instead of an error message while running svn co, it would be nice to have an
option to disable symbolic l
82 matches
Mail list logo
