Noorul Islam K M writes:
> When I was trying to come up with a patch for issue 3713, I observed the
> following.
>
> For example I have two files 1.txt and 2.txt in a repository located at
> file:///tmp/testrepo
>
> svn cat behaves differently for local paths and URLs. See the
> illustration belo
Julian Foad writes:
> On Tue, 2010-11-30 at 18:42 +0530, Noorul Islam K M wrote:
>
>> Julian Foad writes:
>>
>> > I tried some potentially invalid inputs to "svn" a week or two ago and
>> > made notes on what I found. Just posting here in case anyone wants to
>> > do something about one or mor
Julian Foad writes:
> I tried some potentially invalid inputs to "svn" a week or two ago and
> made notes on what I found. Just posting here in case anyone wants to
> do something about one or more of them.
>
> Noorul, I'm including you in the "To" addresses because you said you
> were looking f
I (Julian Foad) wrote:
> > Julian Foad writes:
> >
> > > I imagine it should be possible to add 'NOT NULL' to these columns
> > > without performing a format bump or writing any upgrade code. Am I
> > > right?
>
> Hyrum Wright wrote:
> > If we're already enforcing it in the C code, I see no pro
On Wed, 2010-12-01, Blair Zajac wrote:
> On 12/1/10 4:38 PM, stef...@apache.org wrote:
> > Author: stefan2
> > Date: Thu Dec 2 00:38:17 2010
> > New Revision: 1041230
> >
> > URL: http://svn.apache.org/viewvc?rev=1041230&view=rev
> > Log:
> > Fix the svn_checksum_to_cstring() docstring to actually
Hi Stefan2.
A good test for whether it's worth making an API accept NULL as an input
is: what proportion of the callers would find that useful? I see there
are about 40 callers in the code base. Would you mind scanning through
them and letting us know?
- Julian
On Thu, 2010-12-02 at 07:51 +02
On Thu, 2010-12-02, Daniel Shahaf wrote:
> julianf...@apache.org wrote on Wed, Dec 01, 2010 at 17:44:50 -:
> > -/** Copy file @a file from location @a src_path to location @a dest_path.
> > - * Use @a pool for memory allocations.
> > +/** Copy the file whose basename or relative path is @a file
On Wed, 2010-12-01, Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Dec 01, 2010 at 12:32:45 +:
> > On Wed, 2010-12-01, stef...@apache.org wrote:
> > > Port (not merge) a fix for a FSFS packing race condition from the
> > > performance branch to /trunk: There is a slight time window
> > > bet
On Thu, 2010-12-02 at 14:05 +0530, Noorul Islam K M wrote:
> Julian Foad writes:
>
> > I tried some potentially invalid inputs to "svn" a week or two ago and
> > made notes on what I found. Just posting here in case anyone wants to
> > do something about one or more of them.
> >
> > Noorul, I'm
On Thu, 2010-12-02 at 13:58 +0530, Noorul Islam K M wrote:
> Julian Foad writes:
>
> > On Tue, 2010-11-30 at 18:42 +0530, Noorul Islam K M wrote:
> >
> >> Julian Foad writes:
> >>
> >> > I tried some potentially invalid inputs to "svn" a week or two ago and
> >> > made notes on what I found. J
On Thu, Dec 02, 2010 at 01:11:44AM -0500, C. Michael Pilato wrote:
> On 12/01/2010 02:14 PM, Hyrum K. Wright wrote:
> > 1.5.8 tarballs are up for testing and signing. The magic revision is
> > r1041089:
> > http://people.apache.org/~hwright/svn/1.5.8/
>
> Summary:
>
>+0 to release, pending
Julian Foad wrote on Thu, Dec 02, 2010 at 12:15:19 +:
> On Wed, 2010-12-01, Daniel Shahaf wrote:
> > Julian Foad wrote on Wed, Dec 01, 2010 at 12:32:45 +:
> > > (2) Doesn't the exact same race exist in *all* uses of
> > > svn_fs_fs__path_rev_absolute()? There are five other calls to it,
>
On Wed, Dec 01, 2010 at 01:14:30PM -0600, Hyrum K. Wright wrote:
> 1.5.8 tarballs are up for testing and signing. The magic revision is
> r1041089:
> http://people.apache.org/~hwright/svn/1.5.8/
1.5.8 is missing the critial blame -g server-side memory leak crash fix.
The trunk revisions merge cl
On 12/02/2010 07:38 AM, Stefan Sperling wrote:
> You need to use serf 0.3.x with Subversion 1.5.
> Subversion 1.6.x includes changes to make it compatible with newer serf
> versions, but those haven't been merged to 1.5.x.
> 1.5.x works fine with serf 0.3.x.
Great, thanks. Now, if we wind up roll
Stefan Sperling writes:
> On Wed, Dec 01, 2010 at 01:14:30PM -0600, Hyrum K. Wright wrote:
>> 1.5.8 tarballs are up for testing and signing. The magic revision is
>> r1041089:
>> http://people.apache.org/~hwright/svn/1.5.8/
>
> 1.5.8 is missing the critial blame -g server-side memory leak crash
On Thu, Dec 2, 2010 at 6:43 AM, Daniel Shahaf wrote:
> [ finally getting back to this mail; having slept on it, etc. ]
>
> Johan Corveleyn wrote on Wed, Dec 01, 2010 at 13:34:48 +0100:
>> On Wed, Dec 1, 2010 at 11:44 AM, Daniel Shahaf
>> wrote:
>> > Johan Corveleyn wrote on Wed, Dec 01, 2010 at
Johan Corveleyn wrote on Thu, Dec 02, 2010 at 14:59:23 +0100:
> On Thu, Dec 2, 2010 at 6:43 AM, Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Wed, Dec 01, 2010 at 13:34:48 +0100:
> >> On Wed, Dec 1, 2010 at 11:44 AM, Daniel Shahaf
> >> wrote:
> >> > Johan Corveleyn wrote on Wed, Dec 01, 2010
On Thu, 2010-12-02 at 14:56 +0200, Daniel Shahaf wrote:
> Julian Foad wrote on Thu, Dec 02, 2010 at 12:15:19 +:
> > Remove the re-try logic from svn_fs_fs__path_rev_absolute(). Since
> > r1040832, all its callers correctly account for the possibility of an
> > out-of-date result due to a concu
On Thu, Dec 2, 2010 at 8:57 AM, Philip Martin
wrote:
> Stefan Sperling writes:
>
>> On Wed, Dec 01, 2010 at 01:14:30PM -0600, Hyrum K. Wright wrote:
>>> 1.5.8 tarballs are up for testing and signing. The magic revision is
>>> r1041089:
>>> http://people.apache.org/~hwright/svn/1.5.8/
>>
>> 1.5.
On 12/02/2010 01:11 AM, C. Michael Pilato wrote:
> On 12/01/2010 02:14 PM, Hyrum K. Wright wrote:
>> 1.5.8 tarballs are up for testing and signing. The magic revision is
>> r1041089:
>> http://people.apache.org/~hwright/svn/1.5.8/
>
> Summary:
>
>+0 to release, pending review of the ra_serf
Julian Foad wrote on Thu, Dec 02, 2010 at 14:33:19 +:
> On Thu, 2010-12-02 at 14:56 +0200, Daniel Shahaf wrote:
> > Julian Foad wrote on Thu, Dec 02, 2010 at 12:15:19 +:
> > > Remove the re-try logic from svn_fs_fs__path_rev_absolute(). Since
> > > r1040832, all its callers correctly accou
Hi Johan.
I've just read the whole of this thread.
I didn't quite understand your original point (2) that "token-based
suffix scanning will not be as fast as byte-based suffix scanning".
Sure it won't, but is there any reason you mentioned suffix scanning
there specifically? The same is true of
Daniel Shahaf wrote:
> Julian Foad wrote on Thu, Dec 02, 2010 at 14:33:19 +:
> > I note that the following comment in pack_shard() is not quite right:
> >
> > /* Update the min-unpacked-rev file to reflect our newly packed shard.
> >* (ffd->min_unpacked_rev will be updated by open_pack_o
Julian Foad wrote on Thu, Dec 02, 2010 at 15:34:48 +:
> First step: this patch fixes the comments. Good to commit?
>
> [[[
> Index: subversion/libsvn_fs_fs/fs_fs.c
> ===
> --- subversion/libsvn_fs_fs/fs_fs.c (revision 1041350)
On Thu, 2010-12-02 at 17:40 +0200, Daniel Shahaf wrote:
> Julian Foad wrote on Thu, Dec 02, 2010 at 15:34:48 +:
> > First step: this patch fixes the comments. Good to commit?
> >
> > [[[
> > Index: subversion/libsvn_fs_fs/fs_fs.c
> > ===
Julian Foad wrote on Thu, Dec 02, 2010 at 15:59:34 +:
> On Thu, 2010-12-02 at 17:40 +0200, Daniel Shahaf wrote:
> > Julian Foad wrote on Thu, Dec 02, 2010 at 15:34:48 +:
> > > First step: this patch fixes the comments. Good to commit?
> > >
> > > [[[
> > > Index: subversion/libsvn_fs_fs/f
On Thu, Dec 02, 2010 at 08:54:35AM -0500, C. Michael Pilato wrote:
> On 12/02/2010 07:38 AM, Stefan Sperling wrote:
> > You need to use serf 0.3.x with Subversion 1.5.
> > Subversion 1.6.x includes changes to make it compatible with newer serf
> > versions, but those haven't been merged to 1.5.x.
>
Note: This email only tangentially relates to svn diff and more about
reverse token scanning in general:
As someone who has implemented suffix reverse token scanning before:
* It simply isn't possible in DBCS code pages. Stick to byte only here.
SBCS and UTF-16 make reverse token stuff relativ
On 12/02/2010 12:18 PM, Bill Tutt wrote:
[...]
. o O ( Who the heck is this Bill Tutt guy? )
Nice to read you again, Bill!
--
C. Michael Pilato
CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
On Thu, Dec 2, 2010 at 8:06 AM, C. Michael Pilato wrote:
> On 12/02/2010 01:11 AM, C. Michael Pilato wrote:
>> On 12/01/2010 02:14 PM, Hyrum K. Wright wrote:
>>> 1.5.8 tarballs are up for testing and signing. The magic revision is
>>> r1041089:
>>> http://people.apache.org/~hwright/svn/1.5.8/
>>
On Thu, Dec 2, 2010 at 4:21 PM, Julian Foad wrote:
> Hi Johan.
>
> I've just read the whole of this thread.
>
> I didn't quite understand your original point (2) that "token-based
> suffix scanning will not be as fast as byte-based suffix scanning".
> Sure it won't, but is there any reason you men
On Thu, Dec 2, 2010 at 6:18 PM, Bill Tutt wrote:
> Note: This email only tangentially relates to svn diff and more about
> reverse token scanning in general:
>
> As someone who has implemented suffix reverse token scanning before:
Thanks for the input. It's nice to see other people have also
stru
On Wed, Dec 01, 2010 at 06:29:06PM -0500, Dan Engel wrote:
> On Wed, 2010-12-01 at 14:08 +0100, Stefan Sperling wrote:
> > However, I still see a potential risk here because the name
> > "gpg-agent"
> > is very misleading. It violates the principle of least surprise.
> > How can we prevent users mi
Johan Corveleyn wrote on Thu, Dec 02, 2010 at 21:21:20 +0100:
> On Thu, Dec 2, 2010 at 6:18 PM, Bill Tutt wrote:
> > If tokens include keyword expansion operations then stop once you
> > hit one. The possible source of bugs outways the perf gain in my mind
> > here.
>
> Haven't thought about k
On Wed, Dec 1, 2010 at 7:34 PM, Philip Martin wrote:
> Daniel Becroft writes:
>
> > Under 1.7.x, the following file(s) are accessed (merging the same
> revision
> > as above):
> >
> > - .svn\wc.db
> > - Every versioned file in the working copy
>
> What does "accessed" mean? stat(), open(), rea
On Thu, Dec 2, 2010 at 3:43 PM, Daniel Becroft wrote:
> On Wed, Dec 1, 2010 at 7:34 PM, Philip Martin
> wrote:
...
>> > I can't see any reason why all these files would need to be accessed. I
>> seem
>> > to recall some discussion about preventing/warning merging into modified
>> > working copies
1.5.9 tarballs are up for testing and signing. The magic revision is r1041577:
http://people.apache.org/~hwright/svn/1.5.9/
To sign the release, please input your signatures using the script here:
http://work.hyrumwright.org/pub/svn/collect_sigs.py
(The script worked pretty well for 1.6.15, but
On Fri, Dec 3, 2010 at 7:50 AM, Hyrum K. Wright <
hyrum_wri...@mail.utexas.edu> wrote:
> On Thu, Dec 2, 2010 at 3:43 PM, Daniel Becroft
> wrote:
> > On Wed, Dec 1, 2010 at 7:34 PM, Philip Martin <
> philip.mar...@wandisco.com>wrote:
> ...
> >> > I can't see any reason why all these files would ne
Daniel Becroft wrote on Fri, Dec 03, 2010 at 08:06:40 +1000:
> On Fri, Dec 3, 2010 at 7:50 AM, Hyrum K. Wright <
> hyrum_wri...@mail.utexas.edu> wrote:
>
> > On Thu, Dec 2, 2010 at 3:43 PM, Daniel Becroft
> > wrote:
> > > On Wed, Dec 1, 2010 at 7:34 PM, Philip Martin <
> > philip.mar...@wandisco.
On 12/02/2010 04:55 PM, Hyrum K. Wright wrote:
> 1.5.9 tarballs are up for testing and signing. The magic revision is
> r1041577:
> http://people.apache.org/~hwright/svn/1.5.9/
Summary:
+1 to release.
Platform:
Ubuntu 10.04 (lucid) Linux.
Tested:
1.5.9 tarball with local dependenci
[Daniel Becroft]
> I've just managed to build/install trunk on my ubuntu box at home (first
> application I've ever compiled on it - yey!).
>
> What debugging tools would you recommend to investigate this further? I've
> seen output posted that lists function names, and time spent on each.
The o
Hi,
This question came up during recent discussion about the
diff-optimizations-tokens branch [1]:
What are the known implementors of svn_diff_fns_t, the vtable of
svn_diff callback functions in subversion/include/svn_diff.h? Besides
the internal diff_memory.c and diff_file.c that is.
Are there
Hi!
I continued the work on my issue.
It seems to be a memory allocation or over-writing problem.
There is the section (see between HEADER_TEXT and HEADER_TEXT OK)
where it calling representation_string, which has to generate the
'text: ...' string. I printed out the input parameters.
Later, ther
43 matches
Mail list logo
