On 19.09.2015 19:20, Ivan Zhakov wrote:
> On 19 September 2015 at 17:24, Ivan Zhakov wrote:
>> On 19 September 2015 at 14:03, Branko Čibej wrote:
>>> On 19.09.2015 13:12, Ivan Zhakov wrote:
On 18 September 2015 at 12:49, Stefan Sperling wrote:
> On Thu, Sep 17, 2015 at 05:41:41PM +0200,
On 19 September 2015 at 21:17, Bert Huijben wrote:
> You wouldn't be able to check the id of the old auth baton once the pool is
> cleaned...
>
I can save old auth baton id in cache_entry once I pass it to
svn_ra_open4() and compare it to the current value in
svn_client_ctx_t.
[..]
> It is possi
On Sat, Sep 19, 2015 at 11:35 PM, Stefan wrote:
> On 19/09/2015 22:48, Johan Corveleyn wrote:
>>
>> On Sat, Sep 19, 2015 at 10:14 PM, Stefan wrote:
>>>
>>> On 19/09/2015 22:00, Johan Corveleyn wrote:
>>
>> ...
>>>
>>> So what is your suggesting then? I doubt that adding a "-dev" suffix to
>>> the
On 19/09/2015 22:48, Johan Corveleyn wrote:
On Sat, Sep 19, 2015 at 10:14 PM, Stefan wrote:
On 19/09/2015 22:00, Johan Corveleyn wrote:
...
So what is your suggesting then? I doubt that adding a "-dev" suffix to the
version number (which is only recorded in the bugtracker and in the
changelog
On 19/09/2015 23:11, Branko Čibej wrote:
On 19.09.2015 22:43, Stefan wrote:
On 19/09/2015 22:23, Branko Čibej wrote:
Nothing would speak from my side against using that scheme, if that
would solve all the concerns also the others have.
I just got the idea that Johan's concern would not be solved
On 19.09.2015 22:43, Stefan wrote:
> On 19/09/2015 22:23, Branko Čibej wrote:
>> On 19.09.2015 22:14, Stefan wrote:
>>> On 19/09/2015 22:00, Johan Corveleyn wrote:
On Sat, Sep 19, 2015 at 9:44 PM, Stefan wrote:
> For once this is not a major concern for MaxSVN, since this aims
> purel
On Sat, Sep 19, 2015 at 10:14 PM, Stefan wrote:
> On 19/09/2015 22:00, Johan Corveleyn wrote:
...
>> Just another observation: on trunk we already put "1.10.0-dev (under
>> development)" as version tag (comes out of 'svn --version' if you
>> build from trunk). So it's not like we're not doing some
On 19/09/2015 22:23, Branko Čibej wrote:
On 19.09.2015 22:14, Stefan wrote:
On 19/09/2015 22:00, Johan Corveleyn wrote:
On Sat, Sep 19, 2015 at 9:44 PM, Stefan wrote:
For once this is not a major concern for MaxSVN, since this aims
purely for
development/testing and not actual usage as an SVN
On 19.09.2015 22:14, Stefan wrote:
> On 19/09/2015 22:00, Johan Corveleyn wrote:
>> On Sat, Sep 19, 2015 at 9:44 PM, Stefan wrote:
>>> For once this is not a major concern for MaxSVN, since this aims
>>> purely for
>>> development/testing and not actual usage as an SVN client in production
>>> env
On 19/09/2015 22:00, Johan Corveleyn wrote:
On Sat, Sep 19, 2015 at 9:44 PM, Stefan wrote:
For once this is not a major concern for MaxSVN, since this aims purely for
development/testing and not actual usage as an SVN client in production
environment.
For 1.10 builds there's also an additional
On 18.09.2015 16:25, Branko Čibej wrote:
> On 18 Sep 2015 4:16 pm, "Ivan Zhakov" wrote:
>> On 18 September 2015 at 16:10, Stefan Sperling wrote:
>>> On Fri, Sep 18, 2015 at 03:47:06PM +0200, Ivan Zhakov wrote:
Attachments was successfully migrated after multiple attempts and help
from A
On Sat, Sep 19, 2015 at 9:44 PM, Stefan wrote:
> For once this is not a major concern for MaxSVN, since this aims purely for
> development/testing and not actual usage as an SVN client in production
> environment.
> For 1.10 builds there's also an additional note pointing that fact out on
> the do
For once this is not a major concern for MaxSVN, since this aims purely
for development/testing and not actual usage as an SVN client in
production environment.
For 1.10 builds there's also an additional note pointing that fact out
on the download page.
Furthermore, the dev builds of 1.10 are a
Just stating the obvious again: Any sources from trunk or a future 1.10.x
branch before 1.10.0 is released is not 1.10 and may be 100% incompatible with
the real 1.10 versions.
Once 1.10 is released how are your users going to see that all the pre
1.10.0.773 (assuming 772 dev builds) are not 1.
You wouldn't be able to check the id of the old auth baton once the pool is
cleaned...
Libsvn_client could do some magic but this would have to be done in every place
where we create/fetch Ra sessions. This makes it even more of a hack than the
current code, while the idea was to clean things u
On 19 September 2015 at 19:49, Evgeny Kotkov
wrote:
> Ivan Zhakov writes:
>
>> Otherwise, here are my ideas at the moment:
>> 1. Add svn_client_ctx2_t with svn_client_context_create3() that's
>> accept AUTH_BATON as parameter. This will require revv all
>> svn_client_*() functions to create new s
Ivan Zhakov writes:
> Otherwise, here are my ideas at the moment:
> 1. Add svn_client_ctx2_t with svn_client_context_create3() that's
> accept AUTH_BATON as parameter. This will require revv all
> svn_client_*() functions to create new svn_client_ctx2_t() on every
> invocation of deprecated funct
On 19 September 2015 at 17:24, Ivan Zhakov wrote:
> On 19 September 2015 at 14:03, Branko Čibej wrote:
>> On 19.09.2015 13:12, Ivan Zhakov wrote:
>>> On 18 September 2015 at 12:49, Stefan Sperling wrote:
On Thu, Sep 17, 2015 at 05:41:41PM +0200, Ivan Zhakov wrote:
> That branch is compl
On 19/09/2015 18:12, Stefan wrote:
On 19/09/2015 16:58, Evgeny Kotkov wrote:
Stefan Hett writes:
You are absolutely right here and I should have seen that before.
Didn't
take that (obvious) point into account at all.
I'll come-up with a working version scheme which won't have
potential for
On 19/09/2015 16:58, Evgeny Kotkov wrote:
Stefan Hett writes:
You are absolutely right here and I should have seen that before. Didn't
take that (obvious) point into account at all.
I'll come-up with a working version scheme which won't have potential for
causing this misinterpretation and wi
On 19 September 2015 at 14:03, Branko Čibej wrote:
> On 19.09.2015 13:12, Ivan Zhakov wrote:
>> On 18 September 2015 at 12:49, Stefan Sperling wrote:
>>> On Thu, Sep 17, 2015 at 05:41:41PM +0200, Ivan Zhakov wrote:
That branch is complete and ready for merging, but I'm still not sure
wh
Stefan Hett writes:
> You are absolutely right here and I should have seen that before. Didn't
> take that (obvious) point into account at all.
>
> I'll come-up with a working version scheme which won't have potential for
> causing this misinterpretation and will make sure that the next releases
On 19/09/2015 16:43, Evgeny Kotkov wrote:
Stefan Hett writes:
I'd imagine the following style could work (it's related to the version
numbering from Visual Assist X (from Wholetomato)):
- MaxSVN-1.9.1-x64 (build 1)
- MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
- MaxSVN-1.10.0-dev-r1701493-x64 (bui
Stefan Hett writes:
> I'd imagine the following style could work (it's related to the version
> numbering from Visual Assist X (from Wholetomato)):
> - MaxSVN-1.9.1-x64 (build 1)
> - MaxSVN-1.9.2-dev-r1701493-x64 (build 1)
> - MaxSVN-1.10.0-dev-r1701493-x64 (build 1)
Let me try to rephrase mysel
Branko Čibej writes:
> I don't mind reordering the 1.9.x entries, but please don't touch
> anything earlier than that because it'd be a real pain to merge to 1.8.x
> and older (that merge is already a bit of a pain, so let's not make it
> worse).
I was not going to touch the /CHANGES, of course.
On 19.09.2015 14:29, Evgeny Kotkov wrote:
> Stefan Hett writes:
>
>> I'm wondering whether it'd be a good idea if entries in the changelog were
>> sorted by its category. This mostly applies to the "Client-side bugfixes"
>> but I think it would slightly improve the readability by users because:
>
Stefan Hett writes:
> I'm wondering whether it'd be a good idea if entries in the changelog were
> sorted by its category. This mostly applies to the "Client-side bugfixes"
> but I think it would slightly improve the readability by users because:
[...]
> Here's how a differently sorted changelo
On 19.09.2015 13:12, Ivan Zhakov wrote:
> On 18 September 2015 at 12:49, Stefan Sperling wrote:
>> On Thu, Sep 17, 2015 at 05:41:41PM +0200, Ivan Zhakov wrote:
>>> That branch is complete and ready for merging, but I'm still not sure
>>> whether we should merge it or not.
>> I think we should merg
On 18 September 2015 at 12:49, Stefan Sperling wrote:
> On Thu, Sep 17, 2015 at 05:41:41PM +0200, Ivan Zhakov wrote:
>> That branch is complete and ready for merging, but I'm still not sure
>> whether we should merge it or not.
>
> I think we should merge it to trunk now.
>
> I don't think this br
First of all thanks for ur input and time Evgeny.
Stefan Hett writes:
What would u say about this other scheme:
1.9.1.1 -> 1.9.1-1-r1694136-dev
1.9.1.2 -> 1.9.1-2
1.9.2.1 -> 1.9.2-1-r1701493-dev
i.e. 1.9.1.2 is a tag-based build on the 1.9.1 branch (therefore it won't
suffix the revision numb
On 19 September 2015 at 11:58, Ivan Zhakov wrote:
> On 18 September 2015 at 10:43, Markus Schaber wrote:
>> Hi,
>>
>> Von: Ivan Zhakov [mailto:i...@visualsvn.com]
>>> On 17 September 2015 at 21:53, Philip Martin
>>> wrote:
>>> > Ivan Zhakov writes:
>>> >
>>> >> I think now is good moment to dis
Hi,
I'm wondering whether it'd be a good idea if entries in the changelog
were sorted by its category. This mostly applies to the "Client-side
bugfixes" but I think it would slightly improve the readability by users
because:
a) it's easier to check the sorted list to see if there were some fix
On 18 September 2015 at 10:43, Markus Schaber wrote:
> Hi,
>
> Von: Ivan Zhakov [mailto:i...@visualsvn.com]
>> On 17 September 2015 at 21:53, Philip Martin
>> wrote:
>> > Ivan Zhakov writes:
>> >
>> >> I think now is good moment to discuss whether we should merge
>> >> ra-reuse-session [1] branc
Hi,
5. What mailing list will issue notifications go to?
We already have
issues@subversion:https://mail-archives.apache.org/mod_mbox/subversion-issues/
That mailing list isn't listed on the mailing-lists page:
http://subversion.apache.org/mailing-lists.html
Was it left out intentionally? Shou
On 18 September 2015 at 17:00, Stefan Sperling wrote:
> On Fri, Sep 18, 2015 at 04:56:04PM +0200, Ivan Zhakov wrote:
>> May be we can put issue tracker on tigris read-only: in this case I
>> could prepare everything today to avoid potential surprises and the
>> time of final migration. Any opinion
35 matches
Mail list logo
