Re: Migrating our wiki

[Johan Corveleyn]

On Sun, Oct 23, 2016 at 10:11 PM, Johan Corveleyn  wrote:
> On Sun, Oct 23, 2016 at 6:25 PM, Daniel Shahaf  
> wrote:
>> Johan Corveleyn wrote on Sun, Oct 23, 2016 at 16:36:58 +0200:
>>> I can't take it any longer ... our (MoinMoin) wiki [1] is so slow that
>>> it's almost unusable.  [,..] So I'd like us to move to
>>> cwiki.apache.org.
>>
>> I prefer moin to confluence (less overhead, no js requirement, etc etc).
>>
>> So I think it'd be nice if we could stick to moin but fix the
>> performance situation.
>>
>> What's infra's position on this?  Is moin supported, or not?  Would
>> a bug about "moin performance is unacceptable" be fixed?
>
> I have no idea. But it's worth a try (having a performant moin wiki
> would be the least work for us at this time), so I'll file a ticket.
> If infra won't fix the performance, we can ask for help doing the
> (semi-)automatic migration from there.

Filed the ticket:
https://issues.apache.org/jira/browse/INFRA-12818 (MoinMoin wiki extremely slow)

-- 
Johan

Re: svn commit: r1764447 - in /subversion/trunk/subversion: libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c

[Stefan Sperling]

On Mon, Oct 24, 2016 at 11:18:51AM +0200, Bert Huijben wrote:
> 
> 
> > -Original Message-
> > From: Stefan Sperling [mailto:s...@apache.org]
> > Sent: maandag 24 oktober 2016 11:08
> > To: dev@subversion.apache.org
> > Subject: Re: svn commit: r1764447 - in /subversion/trunk/subversion:
> > libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c
> > 
> > On Sun, Oct 23, 2016 at 03:31:22PM -0400, James McCoy wrote:
> > > On Wed, Oct 12, 2016 at 12:34:19PM -, s...@apache.org wrote:
> > > > Modified: subversion/trunk/subversion/libsvn_client/conflicts.c
> > > > URL:
> >
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/confl
> ic
> > ts.c?rev=1764447=1764446=1764447=diff
> > > >
> > 
> > ==
> > > > --- subversion/trunk/subversion/libsvn_client/conflicts.c (original)
> > > > +++ subversion/trunk/subversion/libsvn_client/conflicts.c Wed Oct 12
> > 12:34:18 2016
> > > > @@ -5666,6 +5726,18 @@ diff_file_added(const char *relpath,
> > > >  FALSE, FALSE, scratch_pool));
> > > >SVN_ERR(svn_io_check_path(local_abspath, _disk_kind,
> > scratch_pool));
> > > >
> > > > +  if (db_kind == svn_node_file && db_kind == svn_node_file)
> > >
> > > Coverity noticed both sides of the && are the same.  Should one side be
> > > "on_disk_kind == svn_node_file" instead?
> > >
> > 
> > Yes indeed, it should. Thanks! I'll fix this when I find time
> > if it's not already been fixed by then.
> 
> Be careful when committing this as an 'obvious fix'. I've seen a very
> similar problem in the conflict code in the past that has very explicit
> tests in our testsuite that verify the current behavior. It is very well
> possible that this is just the same code moved to a different location.
> 
> If this is that specific case the problem should be fixed, but it won't be
> an obvious fix... more a case of careful review of all the cases that
> trigger this code and then updating expected results.
> 
>   Bert

Yeah, that's why I didn't commit it myself on the spot.
It needs at least one run through the test suite.

RE: svn commit: r1764447 - in /subversion/trunk/subversion: libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c

[Bert Huijben]

> -Original Message-
> From: Stefan Sperling [mailto:s...@apache.org]
> Sent: maandag 24 oktober 2016 11:08
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1764447 - in /subversion/trunk/subversion:
> libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c
> 
> On Sun, Oct 23, 2016 at 03:31:22PM -0400, James McCoy wrote:
> > On Wed, Oct 12, 2016 at 12:34:19PM -, s...@apache.org wrote:
> > > Modified: subversion/trunk/subversion/libsvn_client/conflicts.c
> > > URL:
>
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/confl
ic
> ts.c?rev=1764447=1764446=1764447=diff
> > >
> 
> ==
> > > --- subversion/trunk/subversion/libsvn_client/conflicts.c (original)
> > > +++ subversion/trunk/subversion/libsvn_client/conflicts.c Wed Oct 12
> 12:34:18 2016
> > > @@ -5666,6 +5726,18 @@ diff_file_added(const char *relpath,
> > >  FALSE, FALSE, scratch_pool));
> > >SVN_ERR(svn_io_check_path(local_abspath, _disk_kind,
> scratch_pool));
> > >
> > > +  if (db_kind == svn_node_file && db_kind == svn_node_file)
> >
> > Coverity noticed both sides of the && are the same.  Should one side be
> > "on_disk_kind == svn_node_file" instead?
> >
> 
> Yes indeed, it should. Thanks! I'll fix this when I find time
> if it's not already been fixed by then.

Be careful when committing this as an 'obvious fix'. I've seen a very
similar problem in the conflict code in the past that has very explicit
tests in our testsuite that verify the current behavior. It is very well
possible that this is just the same code moved to a different location.

If this is that specific case the problem should be fixed, but it won't be
an obvious fix... more a case of careful review of all the cases that
trigger this code and then updating expected results.

Bert

Re: svn commit: r1764447 - in /subversion/trunk/subversion: libsvn_client/conflicts.c tests/libsvn_client/conflicts-test.c

[Stefan Sperling]

On Sun, Oct 23, 2016 at 03:31:22PM -0400, James McCoy wrote:
> On Wed, Oct 12, 2016 at 12:34:19PM -, s...@apache.org wrote:
> > Modified: subversion/trunk/subversion/libsvn_client/conflicts.c
> > URL: 
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/conflicts.c?rev=1764447=1764446=1764447=diff
> > ==
> > --- subversion/trunk/subversion/libsvn_client/conflicts.c (original)
> > +++ subversion/trunk/subversion/libsvn_client/conflicts.c Wed Oct 12 
> > 12:34:18 2016
> > @@ -5666,6 +5726,18 @@ diff_file_added(const char *relpath,
> >  FALSE, FALSE, scratch_pool));
> >SVN_ERR(svn_io_check_path(local_abspath, _disk_kind, scratch_pool));
> >  
> > +  if (db_kind == svn_node_file && db_kind == svn_node_file)
> 
> Coverity noticed both sides of the && are the same.  Should one side be
> "on_disk_kind == svn_node_file" instead?
> 

Yes indeed, it should. Thanks! I'll fix this when I find time
if it's not already been fixed by then.

> Cheers,
> -- 
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB