Add --non-interactive to the svn checkout

[akshetpandey]

Otherwise svn checkout hang on an input from user about saving plaintext passwords

+ eval 'svn checkout --username '\''anonymous'\'' --password '\'''\'' '\''http://svn.xvid.org/trunk/xvidcore@2200'\'' xvid && cd xvid'
++ svn checkout --username anonymous --password '' http://svn.xvid.org/trunk/xvidcore@2200 xvid

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <http://svn.xvid.org:80> Xvid's Subversion repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes

[BtbN]

What triggers this to happen? CI is happy and a local build also works fine for me.

[akshetpandey]

I reproduced under multiple envs with a clean master checkout, maybe try clearing the build cache before running?

[BtbN]

I have updated that package not too long ago, and it went through without a hitch.
So I'm a bit confused why it would behave differently all of a sudden, and only for some people.

The change looks simple enough really, but something else must be at play there.
I have just locally confirmed that it indeed runs through just fine, which has me further confused.

[akshetpandey]

The checkout is happening in the container right? Weird that it is inconsistent.
I wonder is something in not pinned exactly right.

The base is pinned to FROM ubuntu:24.04
My build used: sha256:d21429c4635332e96a4baae3169e3f02ac8e24e6ae3d89a86002d49a1259a4f7 for the base image, aka ubuntu:noble-20240429.
svn version is 1.14.3-1build4

[BtbN]

Yeah, should be the same here, I cleaned out all cache before testing.
My only guess would be that the server itself is inconsistent and only sometimes asks for auth.
In any case, I doubt this change breaks anything, so I'm happy to merge it so it catches those few odd one outs.