I also tested on latest arc version no change:
/data/arc/arcanist/bin/arc version
arcanist dae2f0073f019221839924b4b1431c6cba5dcdda (10 Dec 2015)
libphutil 230c3e161c9ad7ee920d003b53e7c4a473a46207 (7 Dec 2015)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Dec 13 2015
Dec 12 2015
Right, I think I have found the cause. The binary_safe_diff.sh does not preserve the exit code of diff, and it returns 0 even if diff returned 1. Apparently returning 0 causes Subversion 1.9 to emit the file headers again.
Yes, 6 months is a huge amount of time in the scale of arc, although that version is probably new enough to have D9921 (although I don't know if July 26 is the changes it actually includes, or just the date someone might have published some earlier version, and have no idea what _2 means).
Dec 10 2015
Dec 5 2015
We haven't seen other requests for this in a year, and our behavior is technically correct and I think it is broadly reasonable.
Dec 2 2015
Nov 28 2015
@epriestley Thanks for the analysis, I'm happy it was easy to reproduce.
Nov 27 2015
This seems straightforward to reproduce:
Nov 26 2015
Nov 22 2015
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.
Nov 21 2015
@joshuaspence what do you think about this issue?
Nov 18 2015
Is there anything I could do to facilitate discussion or acception of this proposal?
Nov 14 2015
Oct 25 2015
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?
Oct 24 2015
Oct 20 2015
Yeah. gotcha. At risk of suggestion solutions and vs. describing problems, certainly the way I think about it is:
- 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?
- 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?
Oct 19 2015
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.
Oct 18 2015
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.
Oct 16 2015
Oct 8 2015
Oct 6 2015
That fixed it. Thanks!
Oct 5 2015
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).
Aug 22 2015
Aug 18 2015
I'm gonna say this is moot now that arcanist project aren't a thing anymore.
Aug 15 2015
Thanks for fixing things up there.
Aug 14 2015
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.
Aug 9 2015
This should be fixed now (see rSVNTEST1).
Jul 28 2015
Jul 23 2015
Jul 3 2015
Jun 11 2015
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 ...
#exitRefresh phabricator's web page.
Hi, how can I check what's the "webuser" of mine?
Jun 10 2015
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
Jun 9 2015
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 ...
#exitRefresh phabricator's web page.
Jun 6 2015
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 ...
#exitRefresh phabricator's web page.
Jun 4 2015
Login as webuser , run svn checkout command and accept the certificate permanently .
Jun 1 2015
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
May 27 2015
As a note, the title tagging you did in D13040: [Redesign] Add back limited header-color options, 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.
May 6 2015
May 5 2015
In T7471#100638, @zzh wrote:And the Subversion server is install over other machine, I'm not the administrator
May 4 2015
@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.
Mar 26 2015
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.
Mar 17 2015
Mar 16 2015
Mar 10 2015
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.
Mar 7 2015
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:
Mar 6 2015
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
Mar 5 2015
Feb 14 2015
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.