We haven't seen other requests for this in a year, and our behavior is technically correct and I think it is broadly reasonable.

@epriestley Thanks for the analysis, I'm happy it was easy to reproduce.

This seems straightforward to reproduce:

In T9784#145136, @andrask wrote:

@joshuaspence what do you think about this issue?

@avivey I'm not sure how I can create a patch for that repo as it has no valid .arcconfig and I don't have the config for the whole Phabricator project. So I just created an svn diff that you can apply locally and then create the patch with your setup. I uploaded it here: https://secure.phabricator.com/F989152

@andrask: I couldn't quite understand what exactly is going on, and what is the expected behavior.

@joshuaspence what do you think about this issue?

Is there anything I could do to facilitate discussion or acception of this proposal?

There is a default pre-commit hook. I don't any custom ones there. If I run it as vcs-user I get a error at this line:
throw new Exception(pht('usage: commit-hook <callsign> <repo> <txn>'));
I'm hesitant to call this exception the same as the issue I see during actual commit because there is no obvious link.

The commit hooks are in hooks/ directory in the working copy /phabdatavol/softwarerepos/TESTPROJ/.

Still looking... nothing useful found. Anyone know what information might be helpful to debug?

Yeah. gotcha. At risk of suggestion solutions and vs. describing problems, certainly the way I think about it is:

1. What is the common prefix of all these file changes (i.e. /repo/projects/tfb/www/trunk/main/production/master/) aka where in the tree did I invoke arc diff?
2. What are the sub-paths w.r.t. the prefix of each file changed (i.e. path/to/file.c)?

It looks like it still has trouble properly rooting the files. Maybe a good way forward here is to always use their absolute path in the repo instead of trying to tie them to some subdir?

Seems like that didn't quite get it yet (see D14301). Below is my transcript:

Adding one is probably the easiest workaround for now.

Ahh, looks like not. We'd been slowly phasing out .arcconfigs since the removal or arcanist projects.

Aah, okay, I misunderstood.

Hmmm, I didn't actually move any files. Maybe this is a derivate of the issue in T9188 then?

When we generate a synthetic diff between diffs "A" and "B", we just use diff and do not apply any move or rename detection on top of it.

That fixed it. Thanks!

I think D14239 fixes this, can you update and let me know if you're still seeing issues?

Thanks for the verification!

I don't see any error trace in my web server logs (/var/log/apache2/error.log, /var/log/apache2/other_vhosts_access.log). I may have been unclear in my description: the error message appears at the top of the Diffusion commit page, but the page appears to work fine otherwise. It seems as if Diffusion is generating an error and catching and showing it but is otherwise working fine.

This install is giving a different error: rSVNTEST3:
svn: E155007: '/core/lib/phabricator/webroot' is not a working copy

rP0db86cce7d was recently landed, you could check it that's the culprit by reverting just that commit. I presume you're pulling HEAD and not Stable?

Can you paste the full error trace? It would be in the webserver's error log.

1.8.8 (as shipped with Ubuntu 14.04, in case that's relevant).

I'm gonna say this is moot now that arcanist project aren't a thing anymore.

Thanks for fixing things up there.

Actually, it might be intentional: When cloning a sub-tree, you probably want the diff to be based off of where you cloned, not the repo root (In case it's very deep, like Facebook used to have).

Ahh, interesting. Yes, I did.

in https://secure.phabricator.com/D13902?id=33558 (The diff you created with arc diff, the file is named lines.
in https://secure.phabricator.com/D13902?id=33559 (The diff which is the actual commit), the file is named dir2/lines.

This should be fixed now (see rSVNTEST1).

In T7471#119519, @nj2408zjw wrote:

In T7471#118340, @harpyham wrote:

Login as webuser , run svn checkout command and accept the certificate permanently .

like this:
#cd /tmp
#su wwwrun -s /bin/sh
#svn co https://ip/svn/pro/xxxxxx
... select permanently ...
#exit

Refresh phabricator's web page.

Hi, how can I check what's the "webuser" of mine?

I've tried many methods, but only this work.
Set your host (displays in your certificate) in /etc/host such as

192.168.1.100 certicaficate_hostname

In T7471#118340, @harpyham wrote:

Login as webuser , run svn checkout command and accept the certificate permanently .

like this:
#cd /tmp
#su wwwrun -s /bin/sh
#svn co https://ip/svn/pro/xxxxxx
... select permanently ...
#exit

Refresh phabricator's web page.

In T7471#118340, @harpyham wrote:

Login as webuser , run svn checkout command and accept the certificate permanently .

like this:
#cd /tmp
#su wwwrun -s /bin/sh
#svn co https://ip/svn/pro/xxxxxx
... select permanently ...
#exit

Refresh phabricator's web page.

Login as webuser , run svn checkout command and accept the certificate permanently .

I installed phabricator using the shell script ( http://www.phabricator.com/rsrc/install/install_rhel-derivs.sh ) and meet the same error. When I run the svn command like

As a note, the title tagging you did in {D13040}, is basically how I've been having users do this in my install. We've been putting the logical project/branch like [branch_name] in a lot of titles to get that info into the major panels so that diffs don't require a clickthrough for context.

In T7471#100638, @zzh wrote:

And the Subversion server is install over other machine, I'm not the administrator

@oujesky, you can use my repo fork https://github.com/aik099/arcanist , that has such functionality via --cl argument arc diff, arc export and arc lint commands.

Any updates on this feature? We are also quite a heavy svn changelist users as it helps a lot when creating more than one change on our working copy.

Thanks again Evan, I can confirm this issue is fixed.

This should be resolved in HEAD. Sorry this took so long to address!

I've just run into this problem as well. This is really a showstopper issue, enough that I may need to abandon using Phabricator/Diffusion for my Subversion hosting.

Especially with the new requirement for a minimum svn version of 1.5, would there be any opposition to removing this check? I'm happy to make a diff for it.

And the Subversion server is install over other machine, I'm not the administrator

I have add the ssl certs like "https://192.168.205.170/rZZH34382", but also have the same problem:

Take a look under the bold heading "Method": http://www.microhowto.info/howto/configure_subversion_to_trust_a_given_ssl_certificate.html

how to set phabricator host ignore invalid ssl certs?

Server SSL certificate verification failed: certificate issued for a different hostname, issuer is not trusted
Im pretty sure that is the issue, either connect over an unsecured connection, generate a valid certificate for the hostname, or have your phabricator host ignore invalid ssl certs

FWIW, I can confirm this as well. My team is having this issue too, though I'm attempting to make Ubuntu our official development platform, so hopefully I will resolve that BEFORE this is fixed.

Its suggested to use Arcanist. e.g.

Hi chad,