On 29.06.2015 23:33, Evgeny Kotkov wrote:
> Evgeny Kotkov writes:
>
>> Do you plan on voting for the corresponding group? If yes, could you please
>> extend the nomination with this JavaHL change? I am then going to look into
>> it more carefully and will update my vote accordingly.
> On the oth
Evgeny Kotkov writes:
> Do you plan on voting for the corresponding group? If yes, could you please
> extend the nomination with this JavaHL change? I am then going to look into
> it more carefully and will update my vote accordingly.
On the other hand, we're just one vote short with the core
Branko Čibej writes:
>> And I have the JavaHL bits done but now I have to leave in 10 minutes,
>> which isn't enough time to review and write the log message. Will commit
>> this evening.
>
> r1688273; I propose we add it to the existing backport proposal.
>From a quick glance, r1688273 looks go
On 29.06.2015 12:20, Branko Čibej wrote:
> On 28.06.2015 22:15, Evgeny Kotkov wrote:
>> Branko Čibej writes:
>>
It would be a nice thing to have, but I am thinking that we should first
nominate this change for a backport to 1.9.x, as we are dealing with an
API change.
Can
On 28.06.2015 22:15, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>>> It would be a nice thing to have, but I am thinking that we should first
>>> nominate this change for a backport to 1.9.x, as we are dealing with an
>>> API change.
>>>
>>> Can we do that without having a complete JavaHL wrappe
Branko Čibej writes:
>> It would be a nice thing to have, but I am thinking that we should first
>> nominate this change for a backport to 1.9.x, as we are dealing with an
>> API change.
>>
>> Can we do that without having a complete JavaHL wrapper for this?
>
> Of course. We've never treated inc
On 26 Jun 2015 5:25 pm, "Evgeny Kotkov" wrote:
>
> Branko Čibej writes:
>
> > I like this a lot. Much better than my hacks upon hacks. :)
> >
> > Please go ahead and commit this. As you said, JavaHL would break after
> > this change. If you like, I can fix it afterwards, but I'm on a rather
> > t
Branko Čibej writes:
> I like this a lot. Much better than my hacks upon hacks. :)
>
> Please go ahead and commit this. As you said, JavaHL would break after
> this change. If you like, I can fix it afterwards, but I'm on a rather
> tight schedule tomorrow and on the week-end so I very likely cou
on of whether a
> particular repository passes the verification or not, without providing a
> root cause (details) of what's wrong.
>
> Discussion can be found in http://svn.haxx.se/dev/archive-2015-05/0141.shtml
> (Subject: "Possible incompatibility of svn_repos_verify_
Evgeny Kotkov writes:
> See the attached patch. Please note that the patch is not a continuation of
> what I posted in my last e-mail (verify-fixup-squashed-v1.patch.txt), but
> from my point of view is better and should address the raised concerns, such
> as having a non-trivial compatibility w
/dev/archive-2015-05/0141.shtml
(Subject: "Possible incompatibility of svn_repos_verify_fs2() in 1.9.0-rc1")
* subversion/include/svn_error_codes.h
(SVN_ERR_REPOS_VERIFY_FAILED): Remove this error code, as we no longer
need to send a specific error from within svn_repos_verify_fs3()
On 19.06.2015 16:41, Evgeny Kotkov wrote:
> Philip Martin writes:
>
>> Branko Čibej writes:
>>
>>> My main objection to this approach is that it breaks all the API
>>> patterns we've ever had: it creates a function that does not return an
>>> error even though it clearly fails, and relies on some
Philip Martin writes:
> Branko Čibej writes:
>
>> My main objection to this approach is that it breaks all the API
>> patterns we've ever had: it creates a function that does not return an
>> error even though it clearly fails, and relies on some notification
>> callback to report actual errors.
Branko Čibej writes:
> My main objection to this approach is that it breaks all the API
> patterns we've ever had: it creates a function that does not return an
> error even though it clearly fails, and relies on some notification
> callback to report actual errors.
We have been reporting errors
Branko Čibej writes:
>> With that in mind, I am -0 on the corresponding backport proposal.
>
> I removed the backport proposal until we get this sorted out.
Ack.
>> I sketched the other possible option with redesigning svn_repos_verify_fs3()
>> API to only report errors via the notify_func(), p
On 15.06.2015 20:54, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>> Evgeny, please take a look at r1684940.
>>
>> I don't really like the fact that with this change and 'svnadmin
>> --keep-going --quiet', the text "Error verifying revision N" gets printed
>> to stderr; but I couldn't think of a
On 15.06.2015 20:54, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>> Evgeny, please take a look at r1684940.
>>
>> I don't really like the fact that with this change and 'svnadmin
>> --keep-going --quiet', the text "Error verifying revision N" gets printed
>> to stderr; but I couldn't think of a
Branko Čibej writes:
> Evgeny, please take a look at r1684940.
>
> I don't really like the fact that with this change and 'svnadmin
> --keep-going --quiet', the text "Error verifying revision N" gets printed
> to stderr; but I couldn't think of a better way to join the error to the
> revision it
Branko Čibej writes:
>> Fine, but I suspect that this fix probably isn't going to address the very
>> last problem in the --keep-going code. It would be a pity to delay
>> Subversion 1.9.0 because of that.
>
> Let's not make the perfect the enemy of the good enough; we'd never have
> released 1.
On 11.06.2015 17:49, Branko Čibej wrote:
> On 11.06.2015 17:34, Evgeny Kotkov wrote:
>> Branko Čibej writes:
>>
>>> If '--quiet' means 'suppress progress', then the result is exactly as
>>> expected. We could change 'svnadmin verify' to behave differently, e.g.,
>>> only display error notification
On 11.06.2015 17:34, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>> If '--quiet' means 'suppress progress', then the result is exactly as
>> expected. We could change 'svnadmin verify' to behave differently, e.g.,
>> only display error notifications in --quiet mode; I agree that would be
>> bett
Branko Čibej writes:
> If '--quiet' means 'suppress progress', then the result is exactly as
> expected. We could change 'svnadmin verify' to behave differently, e.g.,
> only display error notifications in --quiet mode; I agree that would be
> better than the current behaviour, but again, this ha
On 11.06.2015 15:29, Branko Čibej wrote:
> I think we're at the point where we're trying to polish the UI. It is
> rather late in the day for that. The minor tweak required in svnadmin to
> emit errors in --quiet mode can be pushed into RC3
Perhaps something along the lines of the patch below. Not
On 11.06.2015 14:33, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>>> Should be fixed in r1684325.
>> Meh ... siliness. It's actually r1684344. The correct fix is in
>> svnadmin; always sending notifications is correct from API users'
>> perspective, too.
> Thanks for looking into this.
>
> Frank
Branko Čibej writes:
>> Should be fixed in r1684325.
>
> Meh ... siliness. It's actually r1684344. The correct fix is in
> svnadmin; always sending notifications is correct from API users'
> perspective, too.
Thanks for looking into this.
Frankly, I cannot say that adding a flag like b->silent_
On 09.06.2015 08:47, Branko Čibej wrote:
> On 08.06.2015 20:22, Branko Čibej wrote:
>> On 08.06.2015 19:06, Evgeny Kotkov wrote:
>>> Branko Čibej writes:
>>>
I completed your patch and committed the fix in r1683311. Please review!
-- Brane
>>> Sorry, I was on vacation last week and
On 08.06.2015 20:22, Branko Čibej wrote:
> On 08.06.2015 19:06, Evgeny Kotkov wrote:
>> Branko Čibej writes:
>>
>>> I completed your patch and committed the fix in r1683311. Please review!
>>>
>>> -- Brane
>> Sorry, I was on vacation last week and couldn't look at this fix earlier.
>>
>> I reviewe
On 08.06.2015 19:06, Evgeny Kotkov wrote:
> Branko Čibej writes:
>
>> I completed your patch and committed the fix in r1683311. Please review!
>>
>> -- Brane
> Sorry, I was on vacation last week and couldn't look at this fix earlier.
>
> I reviewed the committed patch and tested how Subversion 1.9
Branko Čibej writes:
>
> I completed your patch and committed the fix in r1683311. Please review!
>
> -- Brane
Sorry, I was on vacation last week and couldn't look at this fix earlier.
I reviewed the committed patch and tested how Subversion 1.9.x behaves with it,
as the change itself got merge
On Wed, Jun 3, 2015 at 2:33 PM, Branko Čibej wrote:
> On 21.05.2015 17:23, Evgeny Kotkov wrote:
> > Subversion 1.9.0-rc1 introduced a new svnadmin verify --keep-going mode
> [1].
> > In order to achieve this, we added a svn_repos_verify_fs3() API function
> and
> > deprecated its predecessor, svn
On 03.06.2015 19:50, Ivan Zhakov wrote:
> On 3 June 2015 at 20:44, Branko Čibej wrote:
>> On 03.06.2015 19:38, Ivan Zhakov wrote:
>>> On 3 June 2015 at 20:29, Branko Čibej wrote:
>>>
An API user who wants an early exit can always trigger the cancel_func
in her notification handler and g
On 3 June 2015 at 20:44, Branko Čibej wrote:
> On 03.06.2015 19:38, Ivan Zhakov wrote:
>> On 3 June 2015 at 20:29, Branko Čibej wrote:
>>
>>> An API user who wants an early exit can always trigger the cancel_func
>>> in her notification handler and get SVN_ERR_CANCELLED in response.
>>>
>> The pr
On 03.06.2015 19:38, Ivan Zhakov wrote:
> On 3 June 2015 at 20:29, Branko Čibej wrote:
>
>> An API user who wants an early exit can always trigger the cancel_func
>> in her notification handler and get SVN_ERR_CANCELLED in response.
>>
> The problem that it's could be hard to distinguish summary e
On 3 June 2015 at 20:29, Branko Čibej wrote:
> On 03.06.2015 17:10, Ivan Zhakov wrote:
>> On 3 June 2015 at 17:19, Branko Čibej wrote:
>>> On 03.06.2015 15:31, Ivan Zhakov wrote:
>
I'm also not sure that we have to return error if we already reported it
via notify_func in
svn_rep
On 03.06.2015 17:10, Ivan Zhakov wrote:
> On 3 June 2015 at 17:19, Branko Čibej wrote:
>> On 03.06.2015 15:31, Ivan Zhakov wrote:
>>> I'm also not sure that we have to return error if we already reported it
>>> via notify_func in
>>> svn_repos_verify_fs3().
>>
>> Out notification mechanism cann
On 3 June 2015 at 17:19, Branko Čibej wrote:
> On 03.06.2015 15:31, Ivan Zhakov wrote:
>
> On 3 June 2015 at 15:33, Branko Čibej wrote:
>
> On 21.05.2015 17:23, Evgeny Kotkov wrote:
>
> Subversion 1.9.0-rc1 introduced a new svnadmin verify --keep-going mode [1].
> In order to achieve this, we add
On 03.06.2015 15:31, Ivan Zhakov wrote:
> On 3 June 2015 at 15:33, Branko Čibej wrote:
>> On 21.05.2015 17:23, Evgeny Kotkov wrote:
>>> Subversion 1.9.0-rc1 introduced a new svnadmin verify --keep-going mode [1].
>>> In order to achieve this, we added a svn_repos_verify_fs3() API function and
>>>
On 3 June 2015 at 15:33, Branko Čibej wrote:
> On 21.05.2015 17:23, Evgeny Kotkov wrote:
>> Subversion 1.9.0-rc1 introduced a new svnadmin verify --keep-going mode [1].
>> In order to achieve this, we added a svn_repos_verify_fs3() API function and
>> deprecated its predecessor, svn_repos_verify_f
On 21.05.2015 17:23, Evgeny Kotkov wrote:
> Subversion 1.9.0-rc1 introduced a new svnadmin verify --keep-going mode [1].
> In order to achieve this, we added a svn_repos_verify_fs3() API function and
> deprecated its predecessor, svn_repos_verify_fs2(), that now calls the newer
> function with keep
On 23.05.2015 13:07, Daniel Shahaf wrote:
> Evgeny Kotkov wrote on Thu, May 21, 2015 at 18:23:22 +0300:
>> SVN_ERR(svn_repos_verify_fs2(repos, 1, 5, NULL, NULL, NULL, NULL, pool));
>>
>> ...would return two different errors depending on the binaries being used,
>> assuming that one of the revisio
Evgeny Kotkov wrote on Thu, May 21, 2015 at 18:23:22 +0300:
> @@ -2464,24 +2452,26 @@ svn_repos_verify_fs3(svn_repos_t *repos,
>cancel_func, cancel_baton,
>iterpool);
>
> +if (err && err->apr_err == SVN_ERR_CANCELLED)
Evgeny Kotkov wrote on Thu, May 21, 2015 at 18:23:22 +0300:
> SVN_ERR(svn_repos_verify_fs2(repos, 1, 5, NULL, NULL, NULL, NULL, pool));
>
> ...would return two different errors depending on the binaries being used,
> assuming that one of the revisions in the [r1:r5] range is corrupted:
>
> (Wi
Subversion 1.9.0-rc1 introduced a new svnadmin verify --keep-going mode [1].
In order to achieve this, we added a svn_repos_verify_fs3() API function and
deprecated its predecessor, svn_repos_verify_fs2(), that now calls the newer
function with keep_going argument set to FALSE.
However, svn_repos_
43 matches
Mail list logo
