> This makes sense. However, since spam is apparently bypassing authorization
> --the index page can't be edited anonymously--and also logging, I was
> concerned
> there is a more critical underlying problem. It might even affect more than
> the index page.
I have upgraded the version of Svnwi
problem is as follows, methinks:
when something fails auth, it still is saved to a reject file, just like
normal svn. the problem is that once something succeeds in auth, then
any rejects are automatically appended. now, we cant just get rid of rejects
in the event that someone mistypes the
This makes sense. However, since spam is apparently bypassing authorization
--the index page can't be edited anonymously--and also logging, I was concerned
there is a more critical underlying problem. It might even affect more than
the index page.
On 2/16/08, felix winkelmann <[EMAIL PROTECTED]
On Feb 17, 2008 12:22 AM, felix winkelmann <[EMAIL PROTECTED]> wrote:
> On Feb 16, 2008 6:32 AM, Jim Ursetto <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > It appears that authorized, legitimate wiki edits to random pages are
> > causing
> > simultaneous commits to the 'index' page, which consists of
On Feb 16, 2008 6:32 AM, Jim Ursetto <[EMAIL PROTECTED]> wrote:
> Hi,
>
> It appears that authorized, legitimate wiki edits to random pages are causing
> simultaneous commits to the 'index' page, which consists of spam in the
> form of an SVN merge conflict.
> Can someone look into this?
>
I thin
Hi,
It appears that authorized, legitimate wiki edits to random pages are causing
simultaneous commits to the 'index' page, which consists of spam in the
form of an SVN merge conflict.
Check `svn log index` and notice that quite a few recent commits follow this
pattern.
For example,
svn diff -r8
