Sorry, folks. I'm a guilty party here, too. I got cranky about a prior
commit that made bogus assumptions about the state of the database,
ultimately annoyin^H^H^H^H^H^H^Hencouraging Bert to make this format bump.
On 04/19/2011 05:37 PM, Greg Stein wrote:
> Bert:
>
> I think you should check w
On Tue, Apr 19, 2011 at 04:46:52PM -, rhuij...@apache.org wrote:
> Author: rhuijben
> Date: Tue Apr 19 16:46:51 2011
> New Revision: 1095130
>
> URL: http://svn.apache.org/viewvc?rev=1095130&view=rev
> Log:
> Remove the 'apply svn:externals from added files' code we introduced during
> the
>
On Tue, Apr 19, 2011 at 17:37, Alan Wood wrote:
> On 19 Apr 2011 at 13:07, Greg Stein wrote:
>> >
>> > On Windows, the path returned by mkdtemp() is something like
>> >
>> > C:\users\billga~1\appdata\local\temp\tmpfoobar
>> >
>> > with no leading slash, so an extra slash makes the URL valid.
>> >
On 19 Apr 2011 at 13:07, Greg Stein wrote:
> >
> > On Windows, the path returned by mkdtemp() is something like
> >
> > C:\users\billga~1\appdata\local\temp\tmpfoobar
> >
> > with no leading slash, so an extra slash makes the URL valid.
> >
> > The directory path could even have spaces in it, if t
Bert:
I think you should check with the community before doing a format
bump. You're cutting us out of the conversation.
-g
On Tue, Apr 19, 2011 at 17:05, wrote:
> Author: rhuijben
> Date: Tue Apr 19 21:05:28 2011
> New Revision: 1095214
>
> URL: http://svn.apache.org/viewvc?rev=1095214&view=r
On Tue, Apr 19, 2011 at 08:40, wrote:
> Author: rhuijben
> Date: Tue Apr 19 12:40:36 2011
> New Revision: 1095064
>
> URL: http://svn.apache.org/viewvc?rev=1095064&view=rev
> Log:
> Update svn_wc__db_base_info_t and svn_wc__db_info_t to be more similar to
> their one path counterparts. Add a few
Did you even run the externals_tests before committing this? Looks
like there is a failure there. On Windows.
On Tue, Apr 19, 2011 at 12:46, wrote:
> Author: rhuijben
> Date: Tue Apr 19 16:46:51 2011
> New Revision: 1095130
>
> URL: http://svn.apache.org/viewvc?rev=1095130&view=rev
> Log:
> Remo
On Tue, Apr 19, 2011 at 11:07, Stephen Butler wrote:
>
> On Apr 19, 2011, at 15:32 , Neels Hofmeyr wrote:
>
>> On Mon, 2011-04-18 at 19:47 -0400, Greg Stein wrote:
>>> Applied in r1094816.
>>>
>>> On Mon, Apr 18, 2011 at 18:44, Greg Stein wrote:
On Mon, Apr 18, 2011 at 07:04, Alan Wood wrot
On Apr 19, 2011 7:17 AM, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_subr/sqlite.c Tue Apr 19 11:16:39
2011
> @@ -536,6 +536,11 @@ svn_sqlite__column_is_null(svn_sqlite__s
> return sqlite3_column_type(stmt->s3stmt, column) == SQLITE_NULL;
> }
>
> +svn_boolean_t
> +svn_sqlite__column_by
On Tue, 2011-04-19 at 17:07 +0200, Stephen Butler wrote:
> On Apr 19, 2011, at 15:32 , Neels Hofmeyr wrote:
>
>
> This attached patch fixes three issues with the script:
> 1) use of file:// when I'm sure that file:/// is correct from previous
> discussions on this list
> >
>
On Apr 19, 2011 12:10 PM, "Hyrum K Wright" wrote:
>...
>
> False. This is a *cache*, meaning, if it is NULL you don't lose any
> information, it may just take longer to get that information. If the
> cache is NULL, neon will populate it as needed for increased
> performance.
>
> Note that the ca
I believe that when ra_serf touches a node, the dav_cache will be set to
null. wc_db basically enforces that.
On Apr 19, 2011 12:11 PM, "C. Michael Pilato" wrote:
> ra_serf in trunk, speaking HTTPv2 with the server, doesn't make use of the
> dav_cache. But I can see how that might be a problem whe
ra_serf uses HTTPv2 which does not use the dav_cache. ra_neon has not been
upgraded to use the new protocol.
When ra_serf talks HTTPv1, it *may* use dav_cache, but we may have just left
that out and taken the speed hit (I don't recall)
Cheers,
-g
On Apr 19, 2011 11:58 AM, "Arwin Arni" wrote:
> H
ra_serf in trunk, speaking HTTPv2 with the server, doesn't make use of the
dav_cache. But I can see how that might be a problem when switching between
serf and neon, because neon *does* consult the dav cache (which in your
case, I'm guessing, must be stale).
At a minimum, if ra_serf isn't going t
On Tue, Apr 19, 2011 at 10:57 AM, Arwin Arni wrote:
> Hi All,
>
> NODES.dav_cache in wc.db is always set to NULL in serf.
>
> Is it intentional?
Yes. Serf does not require this cache.
> If not attached patch would fix it.
>
> Why I am concerned?
>
> I was testing one scenario(master-slave setup
On 04/19/2011 07:44 AM, Mark Phippard wrote:
On Mon, Apr 18, 2011 at 7:41 AM, Daniel Shahaf wrote:
On Mon, 18 Apr 2011 07:08 -0400, "Mark Phippard" wrote:
I know why it fails, but I would not expect it to fail as a user, even
with a proxy. I did not look at Arwin's test but it does not requi
Hi All,
NODES.dav_cache in wc.db is always set to NULL in serf.
Is it intentional?
If not attached patch would fix it.
Why I am concerned?
I was testing one scenario(master-slave setup) which failed becuase of
NODES.dav_cache being NULL.
Scenario:
I was trying to understand r900797(Commit
On Apr 19, 2011, at 15:32 , Neels Hofmeyr wrote:
> On Mon, 2011-04-18 at 19:47 -0400, Greg Stein wrote:
>> Applied in r1094816.
>>
>> On Mon, Apr 18, 2011 at 18:44, Greg Stein wrote:
>>> On Mon, Apr 18, 2011 at 07:04, Alan Wood wrote:
Hi devs,
I have just been looking at running the
On Mon, 2011-04-18 at 19:47 -0400, Greg Stein wrote:
> Applied in r1094816.
>
> On Mon, Apr 18, 2011 at 18:44, Greg Stein wrote:
> > On Mon, Apr 18, 2011 at 07:04, Alan Wood wrote:
> >> Hi devs,
> >> I have just been looking at running the benchmarks and have got to the
> >> stage where I can
In getting 1.7 to work with Subclipse I ran into some problems where
it seems that JavaHL does not have the same thread-safety that
previous versions had. Bert seemed to indicate that what was working
in earlier versions was probably just luck. In current Subclipse
versions, I construct one, and
"C. Michael Pilato" writes:
>> + if (changed_path && changed_path->prop_mod)
>> +break;
>> + if (svn_dirent_is_root(path, strlen(path)))
>
> I'd need to get my bearings before reviewing the meat of this change, but
> this use of the wrong path API caught my eye. These aren't di
On 04/18/2011 02:38 PM, phi...@apache.org wrote:
> Author: philip
> Date: Mon Apr 18 18:38:58 2011
> New Revision: 1094692
>
> URL: http://svn.apache.org/viewvc?rev=1094692&view=rev
> Log:
> Make "blame -g" more efficient on the server when svn:mergeinfo is
> large.
>
> * subversion/libsvn_repos/
22 matches
Mail list logo
