Great, big thanks.

I understand. Then please tell me one thing (I hope that's not complex): how to determine which controller have processed an url?

@epriestley , if I'm about to implement this in my local fork, could you please tell me:

Maybe you can do as Atlassian FishEye did: for each repository defined a regex to determine trunk/branch/tag (3 separate regexps). Then we can match path of 1st file in commit (hopefully nobody will do cross-branch/tag commits) and detect branch/tag.

As we've already discussed that task is far from it's implementation. Until then current API call works, why mark it as deprecated and prevent anybody willing to add comment to commit from seeing that call on /conduit/ page. I guess deprecation status only affects visibility of that API call, but it still continues to work.

I've found that there is API call for creating comments for commits called diffusion.createcomment, but it's marked as deprecated. Any idea why? It looks like working one to me.

Can this be implemented this year? Would be great present for Christmas.

@voldern , have you implemented that in your local fork or found another way how to achieve this?

Unfortunately it's one way trip, because if I update SVN then I also need to update all my working copies in 1.6 format to make them compatible. And I will then hit known SVN 1.7 bug with SQLLite database (that's what lives in .svn folders now) locking over Samba/NFS mounted drives (when several programs are attempting to access same working copy at same time and only one will succeed).

That's reassuring statement :)

Are you sure, that Wishlist priority can be applied in this case, because all necessary code changes are already made in D10772 revision. So it's just a matter of reviewing.

If people are using arc land to do a commit. Although reading documentation I've noticed that nobody is forced to use arc land and can commit in any way they want.

I've made necessary changes and now trying to use arc diff to submit them here. However I encounter the problem, where linter is complaining about trailing whitespaces and tabs within new patch fixture I've used. Linter validations are normal for PHP files, but I think that they shouldn't apply to patch files.

It's ok if you don't merge it to the upstream (I can merge it my fork regardless of this). But what I'm asking if implementation is correct and code is following Phabricator coding guidelines and such. Maybe this needs to be unit tested somehow?

Also if a new revision is created through the Web Interface and repository is specified, then it isn't saved. For example on http://qa.in-portal.org/D9 from action history you can see that repository was set on the form, but no repository appearing by the fact:

@rudykocur , does the change you've made work as expected and no issues were found so far?

I will do that, thanks.

+1 from me.

I've created my own fork, so I guess now I can change something locally to make it work.

So you pre-generate context by arcanist based on code of the working copy. And Show 10 more lines doesn't really point back to changed file it's just text that comes in with a patch.

• interesting, why this field is made editable if changing it have no effect on revision it self
• can you please point in place in the code, that is responsible for context setting from arc diff command?

On a personal note, please take time and try to be respectful of our feedback and decisions.

But what is really preventing you from adding that argument for SVN workflow? It won't hurt anybody. Not adding this just because it's an answer. As I said before you can always revert if something will come up.

Care to share why? Also what about SVN users of Phabricator? Do they have the same issue?

does arc patch under SVN checks that the workspace is clean?

Do you have any Phabricator user, who use SVN repositories? I wonder what workflow they are using.

Due the inability to split changes by branches (like in Git) my SVN workflow is to have multiple files changed related to several issues at same time. I group them together using SVN changelist feature. Unfortunately arc diff doesn't take SVN changelists into account and creating revision based on all changes files in working copy, which is not what I need. Because of this I create patch from changeset manually and upload it to Differential via Web Interface. In this scenario Differential can see the SVN revisions in patch file, but it doesn't know the repository they are associated with and therefore has empty context.

So it's the git repo workflow (with branch creation) that is preventing .orig files from being created in your case.

Can you cleanly arc patch from secure.phabricator.com?

That's the thing: there are no conflict. You can see that lines are shifted a bit in a file and with fuzz factor of 1 hunk was applied. You can see that clearly on my scenario.

@chad, so you're saying that following my instructions you don't get .orig files created? Which patch version is on your side? Mine is:

That's no workaround, because actual patch command is invoked from within the Arcanist. That argument is needed to be added in it.

Actually number of files in commit is displayed for commits in Diffusion, e.g. Changes (5). So doing same for Differential would just make this behaviour consistent.

I've debugged arc patch command and defietely after https://github.com/phacility/arcanist/blob/master/src/workflow/ArcanistPatchWorkflow.php#L582-L587 lines are invoked I got my files patched and .orig files present.

Nope, this was solved by recent changes and now all Herald-rule marked commits have nice orange "Audit Require" badge on them.

I'm using SVN 1.6 working copy.

Luckily the existing repos, that are configured with file:// protocol are still working. I hope you won't be removing that.

Also I believe, that in Notifications app the "Unread Notifications" query should be default, not "All Notifications" as it is now.

Isn't having "Mark as Read" link on list of already read notifications controversial? Usually when people click on something, then something should happen/change, but it doesn't in this case.

Looks like a step in the right direction. Still doesn't explain Herald behavior change.

Also it's kind of strange to have orange badge (on commit list) for audit required status and blue exclamation mark (on commit detail page) at the same time.

At company I'm working at we have workflow, where people must prefix 1st commit message line with reference to fixed commit like so: [fixes: rABC434353] (space at the end).

In fact everything is connected. I've found, that blue exclamation mark next to auditor indicates, that audit is required (see https://github.com/phacility/phabricator/blob/master/src/applications/diffusion/controller/DiffusionCommitController.php#L1067-L1072) and dark exclamation mark next to auditor indicates that audit is requested (see https://github.com/phacility/phabricator/blob/master/src/applications/diffusion/controller/DiffusionCommitController.php#L1085-L1090).

One thing I haven't noticed from

I'm also curious about these exclamation mark icon colors next to auditor usernames in commit. I think badge color might be related to some in some way. Is there any documentation about Phabricator UI, e.g. what interface element means what?

Is there any way to determine which particular settings were responsible for that email? I have commit and auditor added mail tags on received email (header: X-Phabricator-Mail-Tags: <audit-commit>, <audit-add-auditors>).

I guess T2497 task might be related. Before I wasn't getting much e-mails about audits, unless somebody added a comment/in-line comment.

I have that ID in the differential_transaction table though. The record says I've removed value from Repository field. And I've created revision manually, not via Arcanist.

Nope, I wasn't doing anything related to that. I just created few Herald rules related to differential. I've opened "differential_revision" table in the "phabricator_differential" database and there is no such PHID PHID-XACT-DREV-2blzexpfugzzn32 in the phid column. I'm wondering from where the item id in the story comes from.

Is there any instruction on how to create local patch and keep update_phabricator.sh script work without causing any conflicts with git pull? If I remember properly then git pull simply won't work when it detects local changes.

Phabricator is great and when I started using it my life changed and I've been code review guru ever since. I also understand that when you choose to install a software, then you're guaranteed to have only functionality it has at that time and can't make any expectation on it beyond that and especially free of charge.

That I understand. But does it really take that much time to just replace 3 mentioned lines in each file within a patch? I bet you spent more time explaining to me twice that you don't care about PhpStorm users.

The http://qa.in-portal.org/rSIM16064 should be http://qa.in-portal.org/rTSIM16064 in previous comment.

This continues to happen. For example:

@epriestley, can this change be made to allow uploading PhpStorm created patches?

If you have View in Editor functionality, then I suppose it worked at some point. I wonder how it was used knowing all problems that I've experienced with it.

You recommend that I create symlinks on my machine and name them like path in SVN repository? Won't it be easier to have per user setting, like editor url, where I specify from=>to replacements pairs to be applied to repository file path before giving it to %f in editor url.

Also the comment textarea in Manifest doesn't clear when I hit Submit button.

Usually host goes till the first ? or if that's missing till the end of the string.

I see.

Isn't parse_url function (http://php.net/manual/en/function.parse-url.php) used to parse url to determine protocol? I thought it handle that stuff without problems.

Probably somebody forgot to update language pack, when decision was made not to support more default editors :)

We're not interested in adding more protocols, which is why it's extendible.