Translation status report for trunk@r1170028
lang trans untrans fuzzy obs
--
de2079 157 328 252 UUoo
es2005 231 355 388 +++UU~
fr2236 0
Quick tweak to reduce allocations on this codepath. LINE->data is
a non-const string so we can just parse it in-place without the full
generality of svn_cstring_split().
[[[
Index: subversion/libsvn_fs_fs/fs_fs.c
===
--- subversion/l
svn_fs_base__get_node_successors() was implemented over 20 months ago.
Right now svn_fs_history_next() has been implemented for both backends
and passes a simple unit test (fs-test 37, node_history()).
https://svn.apache.org/repos/asf/subversion/branches/fs-successor-ids/subversion/include/svn_fs
[RFC] In new code, rename RESULT_POOL and SCRATCH_POOL to RESULT and
SCRATCH, respectively.
Because the names are too long and C is strongly typed.
--
(This has been on my mind since some time, I probably mentioned it in
passing a few times already, I don't think I've RFC'd it yet.)
Daniel Shahaf wrote on Tue, Sep 13, 2011 at 03:27:07 +0300:
> On the fs-successor-ids branch we store 64bit ints in big endian format
> in one of the files. The following patch changes the function which
> reads that file such that it returns an apr_off_t offset (which is
> convenient for further
On the fs-successor-ids branch we store 64bit ints in big endian format
in one of the files. The following patch changes the function which
reads that file such that it returns an apr_off_t offset (which is
convenient for further processing), and in return moves and changes the
overflow check.
I'
On Mon, Sep 12, 2011 at 2:17 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> and the commit failed compaining the a/b/E is missing. Now that commit
>> works, on case-sensitive and case-insensitive filesystems, when the
>> added tree is a mv with copyfrom. Marc's mail appears to show that
On Fri, Sep 9, 2011 at 9:02 PM, Hyrum K Wright
wrote:
> In accordance with my aforementioned intent, I've rolled 1.7.0-rc3
> from the latest bits on the 1.7.x branch, and posted them here for
> testing / signing:
> http://people.apache.org/~hwright/svn/1.7.0-rc3/
>
> The magic revision is r1167356
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
Hyrum K Wright wrote on Mon, Sep 12, 2011 at 16:11:04 -0500:
> On Mon, Sep 12, 2011 at 2:06 PM, Daniel Shahaf
> wrote:
> > Look. You're just wrong. SVN_ERR() always implies svn_error_trace()
> > regardless of SVN_ERR__TRACING, and there is no additional branch here
> > in an optimized build (an
Oh, I think that's a good idea! I'll go ahead and revert r1169851 now
in the hopes of implementing this in the next day or so.
-Hyrum
On Mon, Sep 12, 2011 at 4:12 PM, Daniel Shahaf wrote:
> How about having the tests use svn_error_raise_on_malfunction() by
> default and svn_error_abort_on_malfu
How about having the tests use svn_error_raise_on_malfunction() by
default and svn_error_abort_on_malfunction() if --allow-segfaults is
passed?
We can then drop the --trap-assertion-failures option.
Hyrum K Wright wrote on Mon, Sep 12, 2011 at 15:46:45 -0500:
> It is no different than passing --t
On Mon, Sep 12, 2011 at 2:06 PM, Daniel Shahaf wrote:
> Look. You're just wrong. SVN_ERR() always implies svn_error_trace()
> regardless of SVN_ERR__TRACING, and there is no additional branch here
> in an optimized build (and last time you were introducing those changes
> someone demonstrated th
On 2011-09-11 21:40, Johan Corveleyn wrote:
On Mon, Sep 5, 2011 at 11:09 PM, David Darj wrote:
On 2011-09-02 00:02, Johan Corveleyn wrote:
On Tue, Aug 30, 2011 at 11:29 PM, David Darjwrote:
On 2011-08-28 20:34, Johan Corveleyn wrote:
Hi,
I get a test failure of svnsync_tests.py 28: copy
It is no different than passing --trap-assertion-failures. I didn't
even know that option existed prior to your mail.
However, --trap-assertion-failures has the unfortunate property that
it isn't enabled by default in a standard 'make check' run, so the
tests still abort() rather than continue.
On Sun, Sep 11, 2011 at 03:56:39PM +0300, Daniel Shahaf wrote:
> I floated on IRC the idea of having the output not try filter out
> inoperative revisions.
That would not completey fix the problem.
In the case we're looking at there is one huge gap in the range of
revisions already merged. So, y
Stefan Sperling wrote on Mon, Sep 12, 2011 at 21:46:41 +0200:
> On Mon, Sep 12, 2011 at 10:06:26PM +0300, Daniel Shahaf wrote:
> > SVN_ERR() always implies svn_error_trace()
> > regardless of SVN_ERR__TRACING, and there is no additional branch here
> > in an optimized build (and last time you were
On Mon, Sep 12, 2011 at 10:06:26PM +0300, Daniel Shahaf wrote:
> SVN_ERR() always implies svn_error_trace()
> regardless of SVN_ERR__TRACING, and there is no additional branch here
> in an optimized build (and last time you were introducing those changes
> someone demonstrated this via disassembly
Revision numbers younger than current.
Those revision numbers may repeat more than once (in the not unlikely
case of repeatedly failing to commit r42).
They will always appear in non-descending order since the node-revs file
is only written to while the write-lock is held.
---
Correct?
How is that different from using svn_error_raise_on_malfunction()?
i.e., from passing --trap-assertion-failures ?
hwri...@apache.org wrote on Mon, Sep 12, 2011 at 18:03:42 -:
> Author: hwright
> Date: Mon Sep 12 18:03:41 2011
> New Revision: 1169851
>
> URL: http://svn.apache.org/viewvc?rev=
Look. You're just wrong. SVN_ERR() always implies svn_error_trace()
regardless of SVN_ERR__TRACING, and there is no additional branch here
in an optimized build (and last time you were introducing those changes
someone demonstrated this via disassembly excerpts).
So, if you want to reduce on bra
On Mon, Sep 12, 2011 at 12:35 PM, Daniel Shahaf wrote:
> hwri...@apache.org wrote on Mon, Sep 12, 2011 at 17:27:29 -:
>> Author: hwright
>> Date: Mon Sep 12 17:27:28 2011
>> New Revision: 1169837
>>
>> URL: http://svn.apache.org/viewvc?rev=1169837&view=rev
>> Log:
>> A couple of minor improvem
hwri...@apache.org wrote on Mon, Sep 12, 2011 at 17:27:29 -:
> Author: hwright
> Date: Mon Sep 12 17:27:28 2011
> New Revision: 1169837
>
> URL: http://svn.apache.org/viewvc?rev=1169837&view=rev
> Log:
> A couple of minor improvements to the Ev2->delta editor shim.
>
> * subversion/libsvn_del
On 09/09/2011 09:02 PM, Hyrum K Wright wrote:
> In accordance with my aforementioned intent, I've rolled 1.7.0-rc3
> from the latest bits on the 1.7.x branch, and posted them here for
> testing / signing:
> http://people.apache.org/~hwright/svn/1.7.0-rc3/
Summary:
+1 to release.
Platform:
I think the key is that what is done to merge for 1.8 have significant
substance not just be a "nice to have". Users aren't indicating
confusion so much as they are indicating performance issues and
mishandled or unhandled use cases. Better information is good, but real
progress on the items giving
On Mon, Sep 12, 2011 at 10:08 AM, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 10:54 AM, Julian Foad
> wrote:
>
>> Heh, well, I did present the thread as "the current behaviour is a
>> problem". I guess I did it that way because it was a bit of detail (in
>> Subversion's overall merge behavio
SUMMARY:
+1 to release
PLATFORM:
Windows 7
VS 2008 SP1
Java 1.6
COMPONENTS:
Apache2.2.19
APR 1.4.5
APR-UTIL1.3.12
OpenSSL 1.0.0a
Neon0.29.6
Serf 1.0.0
ZLib 1.2.4
SQLite 3.7.7.1
VERIFIED:
signature and sha1
TESTE
Julian Foad wrote on Mon, Sep 12, 2011 at 15:54:40 +0100:
> whereas the larger topic that I'm really interested in is currently
> quite hand-wavy open-ended thinking about what we *could* do, and thus
> harder to email about.
It seems you just described 'obliterate' :)
On Mon, Sep 12, 2011 at 10:54 AM, Julian Foad wrote:
> Heh, well, I did present the thread as "the current behaviour is a
> problem". I guess I did it that way because it was a bit of detail (in
> Subversion's overall merge behaviour) that was easy to latch on to and
> easy to say something spec
On Mon, 2011-09-12 at 10:47 -0400, C. Michael Pilato wrote:
> On 09/12/2011 09:58 AM, Julian Foad wrote:
> > I take some offence at that. Sure it's a not a problem that's been
> > proven to need solving -- and I agree it quite likely is low on the
> > priority list in pragmatic terms. I DON'T ASK
On Mon, 2011-09-12 at 15:33 +0100, Julian Foad wrote:
> On Mon, 2011-09-12 at 10:00 -0400, Mark Phippard wrote:
> > On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad
> > wrote:
> > >> If merge brought in legitimate
> > >> > changes to the svn:mergeinfo property. diff is supposed to show the
> > >>
On Mon, 2011-09-12 at 10:41 -0400, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 10:37 AM, Mark Phippard wrote:
> > I have a working copy of trunk and I do the merge shown as r14 (which
> > is what will be created when I commit this merge). Here is the
> > command I run and the diff output of th
On 09/12/2011 09:58 AM, Julian Foad wrote:
> I take some offence at that. Sure it's a not a problem that's been
> proven to need solving -- and I agree it quite likely is low on the
> priority list in pragmatic terms. I DON'T ASK YOU TO FIX IT. But I'm
> interested more in the theory and the pot
On Mon, Sep 12, 2011 at 10:37 AM, Mark Phippard wrote:
> I have a working copy of trunk and I do the merge shown as r14 (which
> is what will be created when I commit this merge). Here is the
> command I run and the diff output of the mergeinfo:
>
> $ svn merge ^/branches/b .
> --- Merging r10 th
On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
> Paul Burba wrote:
>> If diff is going to take
>> inherited mergeinfo into account (which in a nutshell is really what
>> you are proposing...I think) then *every* child path under an
>> (inheritable) explicit mergeinfo change should show a diff
On Mon, Sep 12, 2011 at 10:00 AM, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
>>> If merge brought in legitimate
>>> > changes to the svn:mergeinfo property. diff is supposed to show the
>>> > changes, and those are changes.
>>
>> I said this is a choice, and tha
On Mon, 2011-09-12 at 10:00 -0400, Mark Phippard wrote:
> On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
> >> If merge brought in legitimate
> >> > changes to the svn:mergeinfo property. diff is supposed to show the
> >> > changes, and those are changes.
> >
> > I said this is a choice, an
On Mon, Sep 12, 2011 at 9:50 AM, Julian Foad wrote:
>> If merge brought in legitimate
>> > changes to the svn:mergeinfo property. diff is supposed to show the
>> > changes, and those are changes.
>
> I said this is a choice, and that if we want to display raw changes to
> the property then that
On Mon, 2011-09-12 at 09:48 -0400, C. Michael Pilato wrote:
> On 09/12/2011 09:24 AM, Paul Burba wrote:
> >>> I'm currently looking at merging from a high-level POV, looking at what
> >>> clues and information we give the users about what they're doing, that
> >>> hopefully guide them in doing the
Paul Burba wrote:
> If diff is going to take
> inherited mergeinfo into account (which in a nutshell is really what
> you are proposing...I think) then *every* child path under an
> (inheritable) explicit mergeinfo change should show a diff right?
No, only if you choose to display that information
On 09/12/2011 09:24 AM, Paul Burba wrote:
>>> I'm currently looking at merging from a high-level POV, looking at what
>>> clues and information we give the users about what they're doing, that
>>> hopefully guide them in doing the Right Thing and don't mislead and
>>> distract them.
>
> Do we have
On Mon, Sep 12, 2011 at 8:52 AM, Mark Phippard wrote:
> On Thu, Sep 8, 2011 at 4:39 PM, Julian Foad wrote:
>> On Thu, 2011-09-08 at 12:37 -0400, Paul Burba wrote:
>>> On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad
>>> wrote:
>>> > Can I file an issue for this?
>>>
>>> Hi Julian,
>>>
>>> What prob
On Mon, Sep 12, 2011 at 8:47 AM, Julian Foad wrote:
> Hi Paul.
>
> Hmm, it's not quite as simple a matter as I first thought.
>
> On Thu, 2011-09-08, Julian Foad wrote:
>> So in "diff" we have a choice. Do we tell the user the physical
>> difference of a particular mergeinfo property, or do we in
I like this patch. We need it.
I found this bogus mergeinfo's were causing 404 file not found,
which were sometimes causing the merge to fail, making it run longer than
necessary.
Few comments.
1.
>opts, args = my_getopt(sys.argv[1:], "h?fRc", ["help", "fix", "recursive",
> "commit"])
If
On Thu, Sep 8, 2011 at 4:39 PM, Julian Foad wrote:
> On Thu, 2011-09-08 at 12:37 -0400, Paul Burba wrote:
>> On Thu, Sep 8, 2011 at 12:08 PM, Julian Foad
>> wrote:
>> > Can I file an issue for this?
>>
>> Hi Julian,
>>
>> What problem(s) is the current behavior causing? I understand your
>> poi
Hi Paul.
Hmm, it's not quite as simple a matter as I first thought.
On Thu, 2011-09-08, Julian Foad wrote:
> So in "diff" we have a choice. Do we tell the user the physical
> difference of a particular mergeinfo property, or do we interpret and
> display what it means? It appears from the wor
Philip Martin writes:
> and the commit failed compaining the a/b/E is missing. Now that commit
> works, on case-sensitive and case-insensitive filesystems, when the
> added tree is a mv with copyfrom. Marc's mail appears to show that it
> fails on Windows when the added tree is a plain add with
I don't think this is a problem with the command line processing
(although it may be a problem with my example, perhaps
# move foo foo_temp
# svn rm foo
# move foo_temp FOO
# svn add FOO
# svn ci
would work better).
However you achieve it, Marc's earlier mail showed the wc.db with a
deleted tree
On Mon, Sep 12, 2011 at 12:37 PM, Philip Martin
wrote:
> Johan Corveleyn writes:
>
>> No, I don't think that's the problem. That should work (can't test
>> right now, being @work, but I don't see why it wouldn't work on
>> Windows). I think the OP means that the following doesn't work:
>>
>> # mo
Johan Corveleyn writes:
> No, I don't think that's the problem. That should work (can't test
> right now, being @work, but I don't see why it wouldn't work on
> Windows). I think the OP means that the following doesn't work:
>
> # move foo FOO
> # svn ci
>
> (i.e. doing the rename outside of svn)
On Mon, Sep 12, 2011 at 12:08 PM, Philip Martin
wrote:
> Marc Strapetz writes:
>
Adding the unversioned directory and removing the missing one
seems to work:
# svn add a/b/E
# svn rm a/b/e
# svn status
! a\b\E
! a\b\E\alpha
! a\b\E\be
Marc Strapetz writes:
>>> Adding the unversioned directory and removing the missing one
>>> seems to work:
>>>
>>> # svn add a/b/E
>>> # svn rm a/b/e
>>> # svn status
>>> ! a\b\E
>>> ! a\b\E\alpha
>>> ! a\b\E\beta
>>> D a\b\e
>>> D a\b\e\alpha
>>> D a\b\e\beta
On 12.09.2011 11:15, Philip Martin wrote:
> Marc Strapetz writes:
>
>> There are some problems when capitalization of a file or directory name
>> changes in the working copy (at least on Windows). I'm starting off with
>> following tree:
>>
>> # svn status -v
>> 11 Marc .
>> 1
Marc Strapetz writes:
> There are some problems when capitalization of a file or directory name
> changes in the working copy (at least on Windows). I'm starting off with
> following tree:
>
> # svn status -v
> 11 Marc .
> 11 Marc a
> 11 Marc
On Mon, Sep 12, 2011 at 10:50 AM, Marc Strapetz
wrote:
> There are some problems when capitalization of a file or directory name
> changes in the working copy (at least on Windows). I'm starting off with
> following tree:
>
> # svn status -v
> 1 1 Marc .
> 1 1 Marc
On Friday 19 August 2011 11:45 AM, Prabhu Gnana Sundar wrote:
Correcting the issue number as #3961...
Minor fix in one of the commented descriptions... Attaching the updated
script.
Please share your thoughts.
Thanks and regards
Prabhu
#!/usr/bin/env python
import svn
import sys
import
There are some problems when capitalization of a file or directory name
changes in the working copy (at least on Windows). I'm starting off with
following tree:
# svn status -v
11 Marc .
11 Marc a
11 Marc a\mu
11 Marc a\b
1
57 matches
Mail list logo
