On 8/12/14 4:39 PM, Branko Čibej wrote:
> This thing against flags and booleans that change API behaviour does have a
> very good argument going for it: it makes the code less obvious for the sake
> of
> saving a few function names.
>
> Consider the standard example, which (these days) would be a
On Tue, Aug 12, 2014 at 11:47 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> Arrgs!! Random key combo made me sent the mail before completing it ...
>
>
> On Tue, Aug 12, 2014 at 11:29 PM, Stefan Fuhrmann <
> stefan.fuhrm...@wandisco.com> wrote:
>
>>
>> On Sun, Aug 10, 2014 at 3:56 P
On 12.08.2014 23:47, Ben Reser wrote:
> On 8/12/14 12:56 PM, Ivan Zhakov wrote:
>> My concerns are the following:
>> 1. Avoid unrelated branch changes
>> 2. Have some function for converting checksum to canonical form:
>>a) one option is just leave svn_checksum_to_cstring_display() and
>> add s
On 8/12/14 3:55 PM, Bert Huijben wrote:
> Since WC-NG we tried not to introduce new functions with flag arguments as in
> general functions like that are hard to maintain, while it is easy to rev
> functions to add another separate argument. (Another less preferred option is
> using a struct with s
Since WC-NG we tried not to introduce new functions with flag arguments as in
general functions like that are hard to maintain, while it is easy to rev
functions to add another separate argument. (Another less preferred option is
using a struct with separate args)
I remember arguments from gste
On 8/12/14 12:56 PM, Ivan Zhakov wrote:
> My concerns are the following:
> 1. Avoid unrelated branch changes
> 2. Have some function for converting checksum to canonical form:
>a) one option is just leave svn_checksum_to_cstring_display() and
> add svn_checksum_to_cstring_display_ex()
>b) a
Arrgs!! Random key combo made me sent the mail before completing it ...
On Tue, Aug 12, 2014 at 11:29 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
>
> On Sun, Aug 10, 2014 at 3:56 PM, Evgeny Kotkov <
> evgeny.kot...@visualsvn.com> wrote:
>
>> Hi Stefan,
>>
>> > Thanks for having a
On 13 August 2014 01:24, Branko Čibej wrote:
> On 12.08.2014 21:56, Ivan Zhakov wrote:
>
> On 11 August 2014 20:51, Ben Reser wrote:
>
> On 8/11/14 1:59 AM, Ivan Zhakov wrote:
>
> My primary concerns was that with svn_checksum_to_cstring_display2()
> we have to care at every place to use proper f
On Sun, Aug 10, 2014 at 3:56 PM, Evgeny Kotkov
wrote:
> Hi Stefan,
>
> > Thanks for having a the (missing) instance ID issue.
> > From initial review, I have 1 objection and 2 issues
> > that your patch does not address, yet.
>
> Thank you for reviewing this patch. I did my best, but I cannot re
On 12.08.2014 21:56, Ivan Zhakov wrote:
> On 11 August 2014 20:51, Ben Reser wrote:
>> On 8/11/14 1:59 AM, Ivan Zhakov wrote:
>>> My primary concerns was that with svn_checksum_to_cstring_display2()
>>> we have to care at every place to use proper flags to get some
>>> canonical representation for
I don't see a problem with not allowing a repository location, but it doesn't
make sense to me to have a revision in that case. You either have both, or have
none.
If you want to tell that the node didn't exist in a revision it makes more
sense to me to tell that it did’t exist at a specific
On 11 August 2014 20:51, Ben Reser wrote:
> On 8/11/14 1:59 AM, Ivan Zhakov wrote:
>> My primary concerns was that with svn_checksum_to_cstring_display2()
>> we have to care at every place to use proper flags to get some
>> canonical representation for protocol/storage.
>
> How about svn_checksum_
On 11 August 2014 20:29, Stefan Fuhrmann wrote:
>
> On Mon, Aug 4, 2014 at 4:23 PM, Ivan Zhakov wrote:
>>
>> On 4 August 2014 17:48, Branko Čibej wrote:
>> > On 04.08.2014 15:22, Ivan Zhakov wrote:
>> >
>> > On 2 August 2014 23:13, wrote:
>> >
>> > @@ -195,7 +206,9 @@ svn_mutex__unlock(svn_mut
I'd like to always make update/switch target revisions available to
the conflict resolver. We currently don't record this information
for tree conflict victims which are not present in the target revision.
For instance, 'svn info' might show:
Tree conflict: local file edit, incoming file delete or
Stefan,
I've noticed another severe issue in named atomic infrastructure used
by revprop caching code while reviewing r1611379 fix:
svn_atomic_namespace__create() doesn't release file lock and
process-wide mutex (!) on error in libsvn_subr\named_atomic.c:446.
Which is basically mean that server w
On 7 August 2014 00:47, Stefan Fuhrmann wrote:
> On Fri, Aug 1, 2014 at 7:37 PM, Ivan Zhakov wrote:
>>
>> On 22 July 2014 01:48, wrote:
>> > Author: stefan2
>> > Date: Mon Jul 21 21:48:35 2014
>> > New Revision: 1612405
>> >
>> > URL: http://svn.apache.org/r1612405
>> > Log:
>> > Follow-up to r
On Tue, Aug 12, 2014 at 12:59 PM, Philip Martin
wrote:
> Philip Martin writes:
>
> > 1. client sends MKCOL
> > 2. apache process MKCOL and populates txn_dir_cache
> > 3. apache sends MKCOL response
> > 4. apache clears MKCOL request pool
> > 5. client sends MERGE
> > 6. apache proces
On 12.08.2014 17:28, s...@apache.org wrote:
> Author: stsp
> Date: Tue Aug 12 15:28:49 2014
> New Revision: 1617507
>
> URL: http://svn.apache.org/r1617507
> Log:
> * subversion/libsvn_subr/debug.c
> (debug_vprintf): Increase local buffer size so clients built with
> SQLITE3_DEBUG don't assert
On Tuesday, August 12, 2014 09:49:08 AM Philip Martin wrote:
> Alexey Neyman writes:
> > Indeed, calling svn_fs_txn_root() after execution of the pre-commit
> > hook in svn_repos_fs_commit_txn() makes Subversion behave in the
same
> > way as it did in 1.6.
>
> Just so I can be clear about what i
Philip Martin writes:
> 1. client sends MKCOL
> 2. apache process MKCOL and populates txn_dir_cache
> 3. apache sends MKCOL response
> 4. apache clears MKCOL request pool
> 5. client sends MERGE
> 6. apache process MERGE
>
> 5 can happen before 4 since two processes are involved but c
Alexey Neyman writes:
> Indeed, calling svn_fs_txn_root() after execution of the pre-commit
> hook in svn_repos_fs_commit_txn() makes Subversion behave in the same
> way as it did in 1.6.
Just so I can be clear about what is happening: can you confirm that you
are not using apache/mod_dav_svn?
Philip Martin writes:
> The txn_dir_cache gets cleared when the pool associated with the
> txn_root is cleared
The net result is that the txn_dir_cache doesn't really work with
apache/mod_dav_svn. Import a directory containing a large number of
small files and the rate at which files are added
22 matches
Mail list logo
