This is more than two years old and no one else seems to have hit it since then. Declining until we see a modern report.

Basic support to (hopefully) support svnsync is now deployed. The Herald stuff would be nice to have eventually, but we don't currently have any real use cases for it.

I believe this is fixed now, but reproduction has always been somewhat elusive so I'm not completely certain. Please let us know if you still see issues after updating. Thanks for the report!

I appear to have found a reproduction case for this in the cluster.

I don't understand what that information has to do with this ticket.

In T11124#179972, @chad wrote:

On your local install or on Phacility test instance?

On your local install or on Phacility test instance?

In T11124#179970, @chad wrote:

You can either point Diffusion in your test instance to the URL of your SVN repository, or if it's behind a firewall and you can't, you can zip it up and add it to the Files area on Phacility and we can manually retrieve it for you.

You can either point Diffusion in your test instance to the URL of your SVN repository, or if it's behind a firewall and you can't, you can zip it up and add it to the Files area on Phacility and we can manually retrieve it for you.

In T11124#179967, @chad wrote:

We need the repository, not the database.

We need the repository, not the database.

I've already import the database dump file. The backup.sql.gz file is the result of ./bin/storage dump.

In T11124#179963, @chad wrote:

Google and Stack Overflow are going to be better resources for things like this, and we're not unfortunately. At least with those sites you can give specific details about what system you have and what you're trying to do, and can get the most up to date answer. All we're going to do here is the same thing, and charge you for our time. That's not great for anyone. :(

Google and Stack Overflow are going to be better resources for things like this, and we're not unfortunately. At least with those sites you can give specific details about what system you have and what you're trying to do, and can get the most up to date answer. All we're going to do here is the same thing, and charge you for our time. That's not great for anyone. :(

We don't offer this service under free support.

In T11124#179960, @chad wrote:

Its up to you to provide us a reproducible bug report under "free support". If you need us to do these steps for you, we'd be happy to, but we charge $1,500 an hour for this.

Its up to you to provide us a reproducible bug report under "free support". If you need us to do these steps for you, we'd be happy to, but we charge $1,500 an hour for this.

In T11124#179958, @chad wrote:

If you're willing you can just import the whole thing into the private test instance and we can inspect it from there.

If you're willing you can just import the whole thing into the private test instance and we can inspect it from there.

In T11124#179954, @chad wrote:

If you can isolate the bad commit and upload a version we can inspect on a test instance on Phacility, we can troubleshoot it further.

• http://phacility.com/
• Click "Try Free"
• Sign up
• Launch a "Test Instance"
• Report back to us if it does not import there.

This isolates any issues with your local copy of Phabricator vs. our hosted platform. It also allows us (with your permission) to privately inspect bad commits for underlying issues.

If you can isolate the bad commit and upload a version we can inspect on a test instance on Phacility, we can troubleshoot it further.

I upgrade Phabricator today.

Thank you. We will upgrade this weekend and report back.

Your versions above are over a year old. Sorry for not catching that sooner.

We don't support old versions of Phabricator. Per documentation we require all bugs and support requests be performed with a current version.

I've read through this article and I am unable to determine what the next step should be. I've already used the repository tool to reparse the bad commit but new commits all go into the same state. One thing to note, my version of the repository tool does not have an --importing flag.

https://secure.phabricator.com/book/phabricator/article/repository_imports/

https://secure.phabricator.com/book/phabricator/article/support/

I created the task, then changed the tags manually (selecting only the tags I felt necessary - also removing the BUG tag). Seems I may have found a bug with the bug tracker. ;)

That is, if you go to the Diffusion workboard, we give you a generic create form instead of a choice between the various normal create forms, currently.

You can file stuff without those tags from workboards, and maybe "Support Request" just got caught in the crossfire of typing every possible tag, so that's a legitimate-albeit-unusual pathway here. But I wouldn't expect the short-lived "New Support Request" form to be accessible any longer.

This tracker is for bug reports and feature requests, and we're surprised you were able to file something without either of those tags.

How did you file this task?

This has been live for some time and appears to have resolved the problems.

Thanks!

Well now I feel silly for not noticing that. I searched for the line number of the error ><

I suspect it's due to the replace status code. Specifically, if a specific path is removed + added, it shows as different than a modify. When this is then copied, it looks like SVN is showing this code for the new path of the file too. See /rSVNTEST8.

rCOREf9b858d57460 gives web nodes sudo access to svnserve when they're proxying SSH connections.

Can this be closed now? I don't think there's enough in here to reproduce.

This has been open for several months without forward progress.

@epriestley I also get this error. What about your fix?

I have the same issue with SVN+SSH, but not with GIT+SSH. I used strace. This is the part where it breaks - looks like it breaks after the chdir call (in the middle of the snippet):

Get a valid certificate or configure your system to trust your self-signed certificate. This is not a problem with Phabricator and I do not plan to support insecure SSL configurations in the upstream.

Any update on this? Th solution proposed by raman is not working for me :(

I am still trying to find a solution to this, but until I do I am considering hosting the SVN repository outside of Phabricator.

Yes, it is possible and that is what I am doing. :] You can point to an entire different server if you want, but we happen to have ^/../other_repo since the externals are on the same server.

Yes, I'm using svn:externals from same repository. I have several base modules stored in repository and projects include these base modules via externals.

Were you using externals? This is specifically about externals which can not be expected to have the same base revision since they are an entirely different repository.

@altendky, when doing svn up the revision for each file in working copy is set to last commit in the repository in general, not last commit when each particular path was changed. This solved problem for me at least when using Subversion 1.6 client.

Sorry @aik099, I guess I totally missed your question last year. In the example, the main repository is correctly listed at revision 203 and the external repository is listed at revision 154. They are separate repositories so it would only be by chance if they ever should be the same number. I will also mention that engine is actually an external of canopen which is an external of the main repository so my propget command isn't particularly relevant.

@silverskysoft that's unfortunate, but thanks for letting me know.

@foven we have not found a solution. We had run out of time to debug SVN. Now we only host GIT repos on Phabricator and SVN is elsewhere.

Just an update:

silverskysoft, did you ever find a solution to this? I seem to be having the same issue.

Thanks for digging into this! That explanation makes SVN's behavior a lot more reasonable.