Translation status report for trunk@r1155200
lang trans untrans fuzzy obs
--
de2075 155 320 252 UUoo
es2001 229 347 389 +++UU~
fr2182 48
On Mon, Aug 08, 2011 at 06:11:42PM +0200, Bert Huijben wrote:
>
>
> > -Original Message-
> > From: s...@apache.org [mailto:s...@apache.org]
> > Sent: maandag 8 augustus 2011 18:05
> > To: comm...@subversion.apache.org
> > Subject: svn commit: r1155001 - in /subversion/trunk/subversion:
>
FYI: We're still lacking one Windows sig for release.
Thanks to all those who have tested and signed thus far.
-Hyrum
On Thu, Aug 4, 2011 at 7:52 PM, Hyrum K Wright
wrote:
> All,
>
> The next prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta3. The magic revision
On Mon, Aug 8, 2011 at 15:33, Hyrum K Wright wrote:
>...
>> First off: we can ignore the specific calls to make it work, but
>> structurally you want something like our *_with_transaction() type of
>> invocation. For every FS vtable entry, it will use this (say)
>> svn_fs_py__invoke_python() call.
On Sun, Aug 7, 2011 at 2:26 AM, Greg Stein wrote:
> On Sat, Aug 6, 2011 at 15:19, Hyrum K Wright
> wrote:
>> On Sat, Aug 6, 2011 at 6:19 AM, Greg Stein wrote:
>>...
>>> From my quick perusal... it seems that you might not be handling
>>> thread states and the GIL. Have I missed something?
>>
>>
On 08/04/2011 08:52 PM, Hyrum K Wright wrote:
> All,
>
> The next prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta3. The magic revision is r1154051 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can find the tarballs h
julianf...@apache.org wrote on Mon, Aug 08, 2011 at 18:32:08 -:
> +++ subversion/trunk/subversion/bindings/ctypes-python/test/remoterepos.py
> Mon Aug 8 18:32:07 2011
> @@ -46,17 +46,24 @@ class RemoteRepositoryTestCase(unittest.
> dumpfile = open(os.path.join(os.path.split(__file__)
I (Julian Foad) wrote:
> Tested:
>
> [...]
> ctypes-python
I had to tweak the ctypes-python tests to get them to run properly. The
pool that the repo's opened in needs to be cleared between tests, to
ensure the rep-cache DB is closed and re-opened when the repo is deleted
and re-created at t
On Thu, 2011-08-04, Hyrum K Wright wrote:
> The next prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta3. [...]
Summary:
+1 to release (Unix).
My two signatures were successfully collected by your script.
Tested:
[ bdb | fsfs ] x [ ra_local | ra_svn | ra_ne
On Mon, Aug 8, 2011 at 1:14 PM, Julian Foad wrote:
> On Mon, 2011-08-08 at 13:11 -0400, Mark Phippard wrote:
>> On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad
>> wrote:
>> On Sat, 2011-08-06, Mark Phippard wrote:
>> > The attached Java program shows a bug in 1.7 when
>>
On Mon, 2011-08-08 at 13:11 -0400, Mark Phippard wrote:
> On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad
> wrote:
> On Sat, 2011-08-06, Mark Phippard wrote:
> > The attached Java program shows a bug in 1.7 when
> calling the
> > getMergeinfoLog API. If
On Mon, Aug 8, 2011 at 5:13 AM, Julian Foad wrote:
> On Sat, 2011-08-06, Mark Phippard wrote:
> > The attached Java program shows a bug in 1.7 when calling the
> > getMergeinfoLog API. If the discoverChangedPaths boolean is
> > set to true we do not get back the expected r
Stefan Küng wrote:
> I've now analyzed the fifth crash report for TSVN that shows a segfault
> when upgrading a working copy. The crash happens here:
>
> libsvn_wc\upgrade.c, line
>
> info = apr_hash_get(*text_bases_info, versioned_file_name,
> APR_HASH
Stefan Küng writes:
> Hi,
>
> I've now analyzed the fifth crash report for TSVN that shows a
> segfault when upgrading a working copy. The crash happens here:
>
> libsvn_wc\upgrade.c, line
>
> info = apr_hash_get(*text_bases_info, versioned_file_name,
> AP
Hi,
I've now analyzed the fifth crash report for TSVN that shows a segfault
when upgrading a working copy. The crash happens here:
libsvn_wc\upgrade.c, line
info = apr_hash_get(*text_bases_info, versioned_file_name,
APR_HASH_KEY_STRING);
with 'version
> -Original Message-
> From: s...@apache.org [mailto:s...@apache.org]
> Sent: maandag 8 augustus 2011 18:05
> To: comm...@subversion.apache.org
> Subject: svn commit: r1155001 - in /subversion/trunk/subversion:
> include/svn_wc.h libsvn_wc/info.c svn/info-cmd.c svn/schema/info.rnc
>
> Au
Summary:
+1 to release
Platform:
Linux (Debian/squeeze)
Tested:
(local, svn, svn+sasl, serf, neon) x (fsfs, fsfs/pack/shard, bdb)
(serf/v1, neon/v1) x (fsfs, bdb)
swig-pl, swig-py, swig-rb
javahl x (fsfs, bdb)
Results:
All tests PASS
Local dependencies:
apache2-threaded-dev
On 08/08/2011 02:05 PM, Stefan Sperling wrote:
> On Mon, Aug 08, 2011 at 06:43:43AM -0500, Hyrum K Wright wrote:
>> On Mon, Aug 8, 2011 at 12:53 AM, Daniel Shahaf
>> wrote:
>>> ne...@apache.org wrote on Mon, Aug 08, 2011 at 02:09:53 +:
Timings for 5x5_1.6
---
Timings for 5x5_tr
I do not think that the reverse merge strategy is the same as doing
multiple forward merges, and I do not think it covers enough cases. For
example, In your original example, you proposed merging in to branch
Feature, where
Feature = F+(R+S+RSFix)
You proposed "unmerging" (or even reverting) to ge
On Mon, Aug 08, 2011 at 06:43:43AM -0500, Hyrum K Wright wrote:
> On Mon, Aug 8, 2011 at 12:53 AM, Daniel Shahaf
> wrote:
> > ne...@apache.org wrote on Mon, Aug 08, 2011 at 02:09:53 +:
> >> Timings for 5x5_1.6
> >> ---
> >> Timings for 5x5_trunk
> >
> > Shouldn't this test the 1.7 branch?
> >
On Mon, Aug 8, 2011 at 12:53 AM, Daniel Shahaf wrote:
> ne...@apache.org wrote on Mon, Aug 08, 2011 at 02:09:53 +:
>> Timings for 5x5_1.6
>> ---
>> Timings for 5x5_trunk
>
> Shouldn't this test the 1.7 branch?
>
> (in addition to, or instead of, trunk)
Alternatively, are we still interested i
On Mon, Aug 08, 2011 at 10:32:55AM -, s...@apache.org wrote:
> Author: stsp
> Date: Mon Aug 8 10:32:54 2011
> New Revision: 1154908
>
> URL: http://svn.apache.org/viewvc?rev=1154908&view=rev
> Log:
> * subversion/bindings/swig/ruby/test/util.rb
> (setup_svnserve): Wait more time for svnserv
On Thu, Aug 04, 2011 at 07:52:10PM -0500, Hyrum K Wright wrote:
> All,
>
> The next prerelease from the 1.7.x branch is now up for testing and
> signing: 1.7.0-beta3. The magic revision is r1154051 (but a known bug
> in the release scripts doesn't include that rev in the header file).
> You can f
On Mon, 2011-08-08 at 11:22 +0200, Miha Vitorovic wrote:
> On 8.8.2011 11:13, Julian Foad wrote:
> > The other day I noticed that the 'svn mergeinfo' command passes
> > changed the parameter to FALSE and found that the result was actually
> > slower. Looking further now, I see that the result is d
On 8.8.2011 11:13, Julian Foad wrote:
The other day I noticed that the 'svn mergeinfo' command passes
changed the parameter to FALSE and found that the result was actually
slower. Looking further now, I see that the result is different.
with svn_client_mergeinfo_log(discover_changed_paths=TR
On Sat, 2011-08-06, Mark Phippard wrote:
> The attached Java program shows a bug in 1.7 when calling the
> getMergeinfoLog API. If the discoverChangedPaths boolean is
> set to true we do not get back the expected results. When it
> is false, the API works properly
26 matches
Mail list logo