On Tue, Mar 16, 2010 at 8:21 AM, Paul Burba wrote:
> On Tue, Mar 16, 2010 at 7:52 AM, Julian Foad wrote:
>> On Mon, 2010-03-15, Paul Burba wrote:
>>> On Fri, Mar 12, 2010 at 12:59 PM, Julian Foad
>>> wrote:
>>> > Hi Paul.
>>> >
>>> > I think we can tighten the validation of svn_merge_range_t to
On Tue, Mar 16, 2010 at 15:59, Philip Martin wrote:
> Greg Stein writes:
>
>> On Tue, Mar 16, 2010 at 13:11, wrote:
>>>...
>>> +++ subversion/trunk/subversion/libsvn_client/copy.c Tue Mar 16 17:11:15
>>> 2010
>>>...
>>> @@ -1150,15 +1149,13 @@ wc_to_repos_copy(svn_commit_info_t **com
>>> apr
Hi all,
The svn_repos_history2() function allows the history_func() to return a
special error, SVN_ERR_CEASE_INVOCATION, to stop the search. This is not
supported in Python bindings, though: attempt to return
core.SVN_ERR_CEASE_INVOCATION from the history receiver results in an
exception:
d
Stefan Sperling wrote:
> On Tue, Mar 16, 2010 at 09:01:28PM +0100, Daniel Näslund wrote:
>> Hi!
>>
>> When trying to replace entries in the status code I got a couple of test
>> failures saying that the revision should be 0 for newly added nodes.
>> Greg pointed out that the entries code set the re
Since you specify "Apache licensed" I assume you are familiar with SVNKit.
By the way, be aware that the Subversion project's compatibility
efforts don't apply to the svn wire protocols, which are only
documented for the convenience of developers. While we aren't going to
go out of our way to brea
On Tue, Mar 16, 2010 at 09:01:28PM +0100, Daniel Näslund wrote:
> Hi!
>
> When trying to replace entries in the status code I got a couple of test
> failures saying that the revision should be 0 for newly added nodes.
> Greg pointed out that the entries code set the revision to 0 for those
> cases
Daniel Näslund wrote:
> Hi!
>
> When trying to replace entries in the status code I got a couple of test
> failures saying that the revision should be 0 for newly added nodes.
> Greg pointed out that the entries code set the revision to 0 for those
> cases while the revision returned from _read_in
Hi!
When trying to replace entries in the status code I got a couple of test
failures saying that the revision should be 0 for newly added nodes.
Greg pointed out that the entries code set the revision to 0 for those
cases while the revision returned from _read_info() sets it to -1.
Should we con
Greg Stein writes:
> On Tue, Mar 16, 2010 at 13:11, wrote:
>>...
>> +++ subversion/trunk/subversion/libsvn_client/copy.c Tue Mar 16 17:11:15 2010
>>...
>> @@ -1150,15 +1149,13 @@ wc_to_repos_copy(svn_commit_info_t **com
>> apr_hash_t *commit_revprops;
>> int i;
>>
>> - /* Find the common r
On Tue, Mar 16, 2010 at 13:11, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_client/copy.c Tue Mar 16 17:11:15 2010
>...
> @@ -1150,15 +1149,13 @@ wc_to_repos_copy(svn_commit_info_t **com
> apr_hash_t *commit_revprops;
> int i;
>
> - /* Find the common root of all the source paths, an
Greg Stein writes:
>> +/* Return in *LOCAL_DIR_ABSPATH the absolute path for the directory
>> + PATH if PATH is a versioned directory. If PATH is not a versioned
>> + directory and LENIENT is FALSE then return an error
>> + SVN_ERR_WC_NOT_WORKING_COPY. If LENIENT is TRUE then failure to
>
Unfortunately, Stefan caught my subtle attempt at self-aggrandizement and
rectified it.
On Mar 16, 2010, at 11:51 AM, s...@apache.org wrote:
> Author: stsp
> Date: Tue Mar 16 16:51:49 2010
> New Revision: 923867
>
> URL: http://svn.apache.org/viewvc?rev=923867&view=rev
> Log:
> * CHANGES: Overw
It's getting to be time for 1.6.10. I'm setting a target branch date of March
31 (with the possibility of an April 1 release :)
So far, we've merged about a dozen items from STATUS into 1.6.x, including a
high-profile #3242 partial fix. There remain another 11 items in STATUS hoping
for revie
On Tue, Mar 16, 2010 at 09:07, wrote:
>...
> +++ subversion/trunk/subversion/libsvn_client/client.h Tue Mar 16 13:07:40
> 2010
> @@ -655,7 +655,8 @@ svn_client__switch_internal(svn_revnum_t
> TARGET is a working-copy path, the base of the hierarchy to be
> compared. It corresponds to the
Paul,
Could you either merge the following item, or create a backport branch? There
is a conflict somewhere in the test.
Thanks,
-Hyrum
On Mar 15, 2010, at 8:34 PM, hwri...@apache.org wrote:
> Author: hwright
> Date: Tue Mar 16 01:34:14 2010
> New Revision: 923536
>
> URL: http://svn.apache.o
On Mar 16, 2010, at 9:45 AM, Martin wrote:
> On 16/03/2010 14:17, Hyrum K. Wright wrote:
>> On Mar 15, 2010, at 10:52 AM, Martin wrote:
>>
>>> First apologies, for I have done this the wrong way round and reported it
>>> already (http://subversion.tigris.org/issues/show_bug.cgi?id=3604).
>>>
On 16/03/2010 14:17, Hyrum K. Wright wrote:
On Mar 15, 2010, at 10:52 AM, Martin wrote:
First apologies, for I have done this the wrong way round and reported it
already (http://subversion.tigris.org/issues/show_bug.cgi?id=3604).
On Windows(Vista) it is possible to mount a partition (
On Mar 15, 2010, at 10:52 AM, Martin wrote:
> First apologies, for I have done this the wrong way round and reported it
> already (http://subversion.tigris.org/issues/show_bug.cgi?id=3604).
>
>
>
> On Windows(Vista) it is possible to mount a partition (partition on the local
> / build-in
On Mon, 2010-03-15, Paul Burba wrote:
> In http://svn.apache.org/viewvc?view=revision&revision=923389 I fixed
> the bug where the order of the rangelist arguments to
> svn_rangelist_intersect() could produce different results. Now the
> intersection of two ranges with different inheritance always
On Tue, Mar 16, 2010 at 7:52 AM, Julian Foad wrote:
> On Mon, 2010-03-15, Paul Burba wrote:
>> On Fri, Mar 12, 2010 at 12:59 PM, Julian Foad
>> wrote:
>> > Hi Paul.
>> >
>> > I think we can tighten the validation of svn_merge_range_t to exclude
>> > change number "r0" (RANGE->start == -1) as in
On Mon, 2010-03-15, Paul Burba wrote:
> On Fri, Mar 12, 2010 at 12:59 PM, Julian Foad
> wrote:
> > Hi Paul.
> >
> > I think we can tighten the validation of svn_merge_range_t to exclude
> > change number "r0" (RANGE->start == -1) as in the following patch.
> >
> > My reasoning is that a change nu
21 matches
Mail list logo
