[Bug] SVN fails to check in files

Development Pipeline & Plugins
, , , ,
1

When I connect to the SVN it says it was successful.

But as soon as I press “Submit to Source Control” and “Ok” the editor says “Failed to check-in!” and then the warning is

Warning Successfully connected to repository Error 404: File Not Found | Assembla

(I omitted the last part with stars)

It makes absolutely no sense.

2

Hi Mads,

Would it be possible for you to provide any information about your repository/assembla setup?

  • Do you have a redirect URI set up?
  • Do you have PIN code authorization or any other additional security?
  • Did you enter your username & password correctly?

I’ve created a TTP issue (318720) to look at this.

3
  • I don’t have any redirect URI set up.
  • I don’t have a PIN Authorization or any additional security.
  • I did check several times that I set it up right since the initial test worked fine.

The only thing that I do have which is not default is that I point to certain DNS servers rather than letting it obtain those automatically.

4

Thanks.
Do you have a log file that you could share with us? If you want, you can redact the URL in the log too.

5

What I posted from that log is all the log I got

6

OK, we will look at this & get back to you soon.

7

Any updates on this?
Kind of crippling development pace :confused:

8

I have a fix pending a new QA build being built.

It looks as if SVN binaries were not supplied with Rocket as they were lost in a merge between branches at some point.

For now, you can work around this by adding the 1.8.1 version of Apache SVN to your Engine\Binaries\ThirdParty directory in your install. Extract the binaries to Engine\Binaries\ThirdParty\svn\Win64 (svn.exe should be in this directory).

With the binaries in place, “Submit To Source Control” may still not work because of the way we batch SVN commands internally (which is what my fix addresses), but you should be able to check files in by right-clicking them in the Content Browser & selecting “Check In” etc.

9

Thanks for the response. The solution you propose sounds a little bit hack-ish or temporary at best. If the new version of Rocket comes around and then tries to fix the issue that the temp fix takes care, whose to say that the new installation won’t just mess up because of this fix?

10

The fix is a temporary workaround & if you are using the regular installer then problems may be caused by this fix. I would advise manually removing the new directory & uninstalling Rocket before installing any subsequent versions.

You can wait until the next Rocket release for the proper fix.

11

For reference, this was fixed in UE4 Main @ CL 1976072.

12

Alright thanks.