On Tue, Jul 19, 2011 at 21:27, Hyrum K Wright wrote:
> Recently I've noticed several people alude to Editor v2 (Ev2) in both
> IRC and on this mailing list. While I know a header file and
> preliminary API has been scoped out, I'm curious as to what The Plan
> is. Are folks trying to get this in
Recently I've noticed several people alude to Editor v2 (Ev2) in both
IRC and on this mailing list. While I know a header file and
preliminary API has been scoped out, I'm curious as to what The Plan
is. Are folks trying to get this into 1.8? What's the general order
for development? What other
On Tue, Jul 19, 2011 at 20:29, Greg Stein wrote:
> On Tue, Jul 19, 2011 at 20:10, Greg Stein wrote:
>> On Tue, Jul 19, 2011 at 17:51, wrote:
>>>...
>>> * subversion/libsvn_client/merge.c
>>> (log_noop_revs): The baton's pool is used in an iterpool pattern so it
>>> must be cleared on each in
On Tue, Jul 19, 2011 at 20:15, Mark Phippard wrote:
> On Tue, Jul 19, 2011 at 8:03 PM, Greg Stein wrote:
>>
>> On Tue, Jul 19, 2011 at 19:18, Daniel Shahaf
>> wrote:
>> >...
>> >> BTW: Someone mentioned using svn 1.7 beta1 and some said it was not
>> >> released yet. Collabnet disagree as beta1
On Tue, Jul 19, 2011 at 20:10, Greg Stein wrote:
> On Tue, Jul 19, 2011 at 17:51, wrote:
>>...
>> * subversion/libsvn_client/merge.c
>> (log_noop_revs): The baton's pool is used in an iterpool pattern so it
>> must be cleared on each invocation of this function.
>> (remove_noop_subtree_range
On Tue, Jul 19, 2011 at 8:03 PM, Greg Stein wrote:
> On Tue, Jul 19, 2011 at 19:18, Daniel Shahaf
> wrote:
> >...
> >> BTW: Someone mentioned using svn 1.7 beta1 and some said it was not
> >> released yet. Collabnet disagree as beta1 is listed here:
> >>
> https://ctf.open.collab.net/sf/frs/do/v
On Tue, Jul 19, 2011 at 17:51, wrote:
>...
> * subversion/libsvn_client/merge.c
> (log_noop_revs): The baton's pool is used in an iterpool pattern so it
> must be cleared on each invocation of this function.
> (remove_noop_subtree_ranges): Make the baton's pool a proper subpool
> to avoid c
On Tue, Jul 19, 2011 at 19:18, Daniel Shahaf wrote:
>...
>> BTW: Someone mentioned using svn 1.7 beta1 and some said it was not
>> released yet. Collabnet disagree as beta1 is listed here:
>> https://ctf.open.collab.net/sf/frs/do/viewRelease/projects.csvn/frs.svn_binaries.windows
CollabNet should
On Tue, Jul 19, 2011 at 19:23, Bert Huijben wrote:
>
>
>> -Original Message-
>> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
>> Sent: woensdag 20 juli 2011 1:19
>> To: Gunnar Dalsnes; dev@subversion.apache.org
>> Cc: us...@subversion.apache.org
>> Subject: Re: 1.7 alpha3 bug (asser
On Tue, Jul 19, 2011 at 10:41, C. Michael Pilato wrote:
>...
> release-readiness? What about ra_serf's "default-ness" -- is it in the
> appropriate state based on that library's readiness at this moment?
The only pending serf issue is my testing of a fix to memory blowup in
ra_serf when somebod
On Wed, Jul 20, 2011 at 6:33 AM, Hyrum K Wright wrote:
> And I citing Mike's concerns about about RC-ness, I'm inclined to make
> this one beta2.
+1. -- justin
Hey Stefan,
On IRC, you asked:
[6:26pm] stsp: question for when you come back from dinner: in
ra_serf, log.c, end_log() -- the log reciever gets info->pool, which
is the same pool the xml parser state uses
[6:27pm] stsp: i wonder if the receiver should be passed a proper
scratch_pool instead
[6:2
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: woensdag 20 juli 2011 1:19
> To: Gunnar Dalsnes; dev@subversion.apache.org
> Cc: us...@subversion.apache.org
> Subject: Re: 1.7 alpha3 bug (assert/exception) during update
>
> tldr for dev@: assertion tha
tldr for dev@: assertion that Gunnar and I can both reproduce easily
using 1.7.0-beta1:
% $svn checkout -q https://zlibnet.svn.codeplex.com/svn test
% $svn update test
(asserts)
Gunnar Dalsnes wrote on Wed, Jul 20, 2011 at 00:59:38 +0200:
> Hi,
>
> Get an exception/assert in svn 1.7 alpha3.
>
On Tue, Jul 19, 2011 at 9:41 AM, C. Michael Pilato wrote:
> On 07/19/2011 10:15 AM, Hyrum K Wright wrote:
>> Since there seems to be consensus regarding not releasing 1.7.0-beta1,
>> I'll clean out STATUS and go roll beta2 this afternoon with the hopes
>> of releasing it by the end of the week.
>>
2011-07-19 18:33:26 Julian Foad napisał(a):
> - The Serf library has support for SSL encryption by relying on
> - the OpenSSL library.
> + The Neon and Serf libraries have support for SSL encryption by
> + relying on the OpenSSL library.
Neon can use GnuTLS instead of OpenSSL.
One alternative solution is having svn_fs_fs__verify() stat() the DB
file for existence before attempting to operate on it.
I don't think it's the most elegant thing in the world, but it avoids
spuriously creating the DB file without complicating the common case
logic.
I'm also open to alternati
Ivan Zhakov wrote on Tue, Jul 19, 2011 at 21:54:19 +0400:
> On Tue, Jul 19, 2011 at 21:46, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Tue, Jul 19, 2011 at 09:45:09 -0400:
> >> On 07/19/2011 03:49 AM, Ivan Zhakov wrote:
> >> > On Mon, Jul 18, 2011 at 23:50, Daniel Shahaf
> >> > wrote:
>
On 7/18/2011 4:37 PM, Folker Schamel wrote:
Hi Andy,
two thoughts about cyclic merges:
1. Merging should not skip cyclic merges (like this old
svnmerge tool), but must subtract (reverse-merge) the original
change first, and then add (merge) the cyclic merge, in order
to not loose adaptions of c
Sure, the removal from the INSTALL file was rather aggressive, in hindsight.
Thanks!
-g
On Tue, Jul 19, 2011 at 12:33, Julian Foad wrote:
> I suggest that information about how to install and use Neon should be
> put back into the INSTALL file. It was removed in r875974 when Serf was
> made the
On Thu, 2011-07-14, Daniel Shahaf wrote:
> I've looked again at the code. Right now it opens the db, with
> svn_sqlite__mode_rwcreate, within an svn_atomic_init_once() block.
>
> Adding the special case "For caller use svn_sqlite__mode_readwrite"
> means we can't use svn_atomic_init_once() any m
On Tue, Jul 19, 2011 at 21:46, Daniel Shahaf wrote:
> C. Michael Pilato wrote on Tue, Jul 19, 2011 at 09:45:09 -0400:
>> On 07/19/2011 03:49 AM, Ivan Zhakov wrote:
>> > On Mon, Jul 18, 2011 at 23:50, Daniel Shahaf
>> > wrote:
>> >> Ivan notes on IRC that this fixes issues with non-ASCII lock tok
C. Michael Pilato wrote on Tue, Jul 19, 2011 at 09:45:09 -0400:
> On 07/19/2011 03:49 AM, Ivan Zhakov wrote:
> > On Mon, Jul 18, 2011 at 23:50, Daniel Shahaf
> > wrote:
> >> Ivan notes on IRC that this fixes issues with non-ASCII lock tokens.
> >> (At least, he reports errors in 'svn ls -v' over
Paul Burba wrote:
> > That (and your r1145653 edit) still looks the wrong way around.
> > Because, unless I'm misreading the double-negatives, this function
> > supposedly returns a set of mergeinfo that refers to *non-existent*
> > path-revs.
>
> Hi Julian,
>
> Ugh, you're correct, I had it comp
On Fri, Jul 15, 2011 at 12:59 PM, Julian Foad wrote:
> Hi Paul. Thanks for the comprehensive reply and sorry for the wait.
> Responses in line.
>
> On Tue, 2011-07-12, Paul Burba wrote:
>> On Fri, Jul 8, 2011 at 1:04 PM, Julian Foad wrote:
>> > Hi Paul. That looks good. I have some queries and
I suggest that information about how to install and use Neon should be
put back into the INSTALL file. It was removed in r875974 when Serf was
made the default.
The attached patch is based on a reverse-merge, but edited to remove
obsolete text (about in-tree builds) and redundant text (extra
desc
On 07/19/2011 10:15 AM, Hyrum K Wright wrote:
> Since there seems to be consensus regarding not releasing 1.7.0-beta1,
> I'll clean out STATUS and go roll beta2 this afternoon with the hopes
> of releasing it by the end of the week.
>
> I'm half-tempted to call it rc1 and start the soak. Thoughts
Since there seems to be consensus regarding not releasing 1.7.0-beta1,
I'll clean out STATUS and go roll beta2 this afternoon with the hopes
of releasing it by the end of the week.
I'm half-tempted to call it rc1 and start the soak. Thoughts?
-Hyrum
On 07/19/2011 03:49 AM, Ivan Zhakov wrote:
> On Mon, Jul 18, 2011 at 23:50, Daniel Shahaf wrote:
>> Ivan notes on IRC that this fixes issues with non-ASCII lock tokens.
>> (At least, he reports errors in 'svn ls -v' over http://; but for me
>> 'ls' and 'info' work fine over svn://.)
>>
>> Are lock
On Mon, Jul 18, 2011 at 23:50, Daniel Shahaf wrote:
> Ivan notes on IRC that this fixes issues with non-ASCII lock tokens.
> (At least, he reports errors in 'svn ls -v' over http://; but for me
> 'ls' and 'info' work fine over svn://.)
>
> Are lock tokens even permitted to be non-ASCII?
> (both ba
30 matches
Mail list logo