[[[
Speeds up LCS algorithm for well-separated sections of change
By exploiting unique matches between the two files, it is possible to
"restart" the LCS algorithm at times and reset the buildup of square
computational complexity.
* subversion/libsvn_diff/lcs.c
(svn_diff__snake_t): Added u
This patch is what I intend to commit just as soon as I get the WC tests
sorted out to install these triggers too. Just posting this now because
I can't commit it till after the weekend.
- Julian
Install the WC DB validation triggers as temporary triggers on opening the
DB, instead of installing
In preparation for installing temp triggers for DB validation, I'm
trying to do a simple factoring-out of a WC DB creation func, but it's
failing. I'm out of time now so if anybody wants to debug for me please
feel free!
Error on running db-test 1 (and others) is:
subversion/libsvn_wc/wc_db_wcroo
On May 27, 2011 11:25 AM, "C. Michael Pilato" wrote:
>...
> > On 05/27/2011 10:55 AM,
> > I .. uh ... broke the world here. Well, at least the svnrdump_tests.py
> > world. Will fix.
> >
>
> This should be fixed in r1128360. Sorry, all.
Thirty minutes from breakage to fixed. You should be flogg
[[[
Faster LCS algorithm in libsvn_diff by reworking fp argument
* subversion/libsvn_diff/lcs.c
(svn_diff__snake): fp and k arguments are added by caller
]]]
Calling svn_diff__snake with fp+k as argument instead of both as
separate arguments reduces running time for the lcs algorithm
substantia
On Fri, May 27, 2011 at 10:43 AM, Morten Kloster wrote:
> My bad; I had forgotten to wrap two of the counting loops in NULL
> checks. This version fixes it. Thanks again for catching that bug,
> Mark.
>
> I've also figured out how to run the test C programs. The new
> version passes all libsvn_dif
On 05/25/2011 05:41 PM, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Thu, May 26, 2011 at 00:36:48 +0300:
>> I've not read the code, but would an array of 'svn_revnum_t[2]' be
>> a better representation?
>>
>> Specifically: an append-only array of [from_rev, to_rev] pairs, sorted
>> by from_rev.
Morten Kloster wrote:
> On Fri, May 27, 2011 at 4:55 PM, Julian Foad wrote:
> > Morten Kloster wrote:
> >> I haven't changed the index/count types yet. What's the right type
> >> to use to get signed 32 bit on 32-bit machines and signed 64 bit
> >> on 64-bit machines?
> >
> > "int"?
>
> Is int gu
[]
>
> I've attached an updated version.
>
And there I go, forgetting the .txt file type again.
HERE is the new version.
Morten
Index: subversion/libsvn_diff/lcs.c
===
--- subversion/libsvn_diff/lcs.c(revision 1128318)
+++
On Fri, May 27, 2011 at 4:55 PM, Julian Foad wrote:
> Morten Kloster wrote:
>> I haven't changed the index/count types yet. What's the right type
>> to use to get signed 32 bit on 32-bit machines and signed 64 bit
>> on 64-bit machines?
>
> "int"?
>
> - Julian
>
>
>
Is int guaranteed to correspon
On Fri, May 27, 2011 at 3:13 PM, Julian Foad wrote:
> On Fri, 2011-05-27 at 13:32 +0200, Johan Corveleyn wrote:
>> On Fri, May 27, 2011 at 12:47 PM, Fuhrmann Stefan (ETAS/ESA1)
>> wrote:
>> > Morten Kloster wrote:
>> >
>> >> [[[
>> >> Simpler/faster LCS algorithm in libsvn_diff by elimination of
If there isn't a pending need, delete it. No point in caring forward
API baggage if we don't need to.
-Hyrum
On Fri, May 27, 2011 at 3:40 AM, Daniel Shahaf wrote:
> Yes, I disable deprecation warnings in my build. (and I indeed didn't do
> the "update existing callers" dance this time)
>
> I'm
On 05/27/2011 11:16 AM, C. Michael Pilato wrote:
> On 05/27/2011 10:55 AM, cmpil...@apache.org wrote:
>> Author: cmpilato
>> Date: Fri May 27 14:55:31 2011
>> New Revision: 1128340
>>
>> URL: http://svn.apache.org/viewvc?rev=1128340&view=rev
>> Log:
>> Make 'svnrdump load --quiet' actually quiet.
>
On 05/27/2011 10:55 AM, cmpil...@apache.org wrote:
> Author: cmpilato
> Date: Fri May 27 14:55:31 2011
> New Revision: 1128340
>
> URL: http://svn.apache.org/viewvc?rev=1128340&view=rev
> Log:
> Make 'svnrdump load --quiet' actually quiet.
>
> * subversion/svnrdump/svnrdump.c
> (load_revisions)
Morten Kloster wrote:
> I haven't changed the index/count types yet. What's the right type
> to use to get signed 32 bit on 32-bit machines and signed 64 bit
> on 64-bit machines?
"int"?
- Julian
My bad; I had forgotten to wrap two of the counting loops in NULL
checks. This version fixes it. Thanks again for catching that bug,
Mark.
I've also figured out how to run the test C programs. The new
version passes all libsvn_diff tests.
I haven't changed the index/count types yet. What's the ri
On Fri, May 27, 2011 at 3:13 PM, Julian Foad wrote:
> On Fri, 2011-05-27 at 13:32 +0200, Johan Corveleyn wrote:
[snip]
>> Maybe some of the performance improvement (and simplification) can be
>> achieved simply by calculating idx0 and idx1 once, and then reusing
>> those variables and pass them
Stephen Butler wrote:
> On May 26, 2011, at 17:56 , Philip Martin wrote:
> > Julian Foad writes:
> >
> >> I am not saying there are no problems with such copies/moves, just I
> >> don't see a problem with the conflict-source info.
> >
> > Issue 3899 is not about repository locations but about th
On Fri, 2011-05-27 at 13:32 +0200, Johan Corveleyn wrote:
> On Fri, May 27, 2011 at 12:47 PM, Fuhrmann Stefan (ETAS/ESA1)
> wrote:
> > Morten Kloster wrote:
> >
> >> [[[
> >> Simpler/faster LCS algorithm in libsvn_diff by elimination of idx.
> >>
> >>* subversion/libsvn_diff/lcs.c
> >> (svn_diff_
"Bert Huijben" writes:
>> I agree that the references to the A/f files should not exist. But I
>> think that that's just a symptom of the issue that a copy of a conflicted
>> item shouldn't be conflicted.
>
> Isn't that the same behavior as we had in 1.0-1.6: a copy is just a copy of
> the actua
On Fri, May 27, 2011 at 12:47 PM, Fuhrmann Stefan (ETAS/ESA1)
wrote:
> Morten Kloster wrote:
>
>> [[[
>> Simpler/faster LCS algorithm in libsvn_diff by elimination of idx.
>>
>>* subversion/libsvn_diff/lcs.c
>> (svn_diff__snake_t): Removed idx parameter (always 0)
>> (svn_diff__lcs_t): Removed i
Morten Kloster wrote:
> [[[
> Simpler/faster LCS algorithm in libsvn_diff by elimination of idx.
>
>* subversion/libsvn_diff/lcs.c
> (svn_diff__snake_t): Removed idx parameter (always 0)
> (svn_diff__lcs_t): Removed idx variable (always 0) , let d have either
> sign, and moved the origo of fp
Yes, I disable deprecation warnings in my build. (and I indeed didn't do
the "update existing callers" dance this time)
I'm happy to go and remove the deprecation decorators from the old API,
if people prefer that. I'm not sure what to do with the new API ---
it's unused currently (other than the
> -Original Message-
> From: Stephen Butler [mailto:sbut...@elego.de]
> Sent: vrijdag 27 mei 2011 12:26
> To: Philip Martin
> Cc: Julian Foad; Subversion Development
> Subject: Re: issue 3899 (copying conflict victims)
>
>
> On May 26, 2011, at 17:56 , Philip Martin wrote:
>
> > Julian
On May 26, 2011, at 17:56 , Philip Martin wrote:
> Julian Foad writes:
>
>> I am not saying there are no problems with such copies/moves, just I
>> don't see a problem with the conflict-source info.
>
> Issue 3899 is not about repository locations but about the
> left/right/mine files in ACTUA
There are a lot of callers for the old API.
I'm kind of with Hyrum here. This new API isn't so much a
next-generation, as it is an API serving different needs. Or more
specifically: the old API of "provide a 'const char *'" is still
entirely valid.
There are a bunch of warnings in the build for t
Diff3 seemed to work fine here in preliminary testing. I'll run
more test, but just in case, which version of the patch did
you use? If you somehow got the .patch file that I included
with my original post, which didn't make it to the archive,
that version had a bug (as noted in my 2nd post). It's
On Tue, May 24, 2011 at 3:10 PM, Justin Erenkrantz
wrote:
>> Either Serf should detect the right error, or Apr should implement a real
>> poll handler on Windows (available since Windows Vista) which should provide
>> more error information.
Well...that's exactly what APR 1.4.x did - but WSAPoll(
28 matches
Mail list logo
