Maybe the hover effect should be changed to zoom while keeping icon position centred.

Ah, then ok. Thought this was a mistake, because nothing else jumps on hover.

Is there any point in showing commit author name, used in VCS system (name & e-mail in git) VS resolved Phabricator username with a link? Then we could have kept 2 line element.

1. create custom query with needed priority filter
2. save query under name of your choosing
3. on panel configuration (that will be used on dashboard) select that saved query from dropdown

This now started to happen on diffusion's commit detail page, when I start to scroll before diffs from all files changed in the commit is loaded via AJAX.

I'm not saying that scrolling isn't working. What I'm saying, and original video attached to task shows, that scrollbar isn't showing up during scrolling. And I guess you must set scrollbars to be hidden by default in OSX interface settings (I'm on Mavericks, no sure if it's issue on Yosemite).

It's not, because this only stopped to work recently and scrollbar is showing fine on any other Phabricator page. For example this task detail page: http://screencast.com/t/b0bTUm41s

What I don't know is why STDIN support was enabled for this linter. If it was enabled just because PHPCS supports STDIN, then surely commit must be reverted because in STDIN mode PHPCS capabilities are limited compared to mode, when you provide file path to it.

Fix is reverting this commit. As noted above when STDIN not used the rulesets which require knowledge of checked filename will be working again.

@joshuaspence, is there alternative to these deprecated options. I'm especially interested with PHPCS linter (see my previous comment)?

This worked before. I guess it was broken with recent changes to how diffusion urls are parsed to create nicer 404 pages for non-existing commits. But maybe I'm completely wrong.

Even after I logout and login again no matter what commit I try to edit I will always seeing edit for for that 1st commit.

@epriestley does this mean you'll merge your fix?

I got an error about trying to write to /var/tmp/aphlict/pid, which did not exist previously as far as I know. P1699 contains the full trace I got.

Author name is mostly visible now, but e-mail (at least for Git repositories) is truncated as well.

Here is how link looks in my implementation:

I wasn't aware of your implementation so I created my own with same purpose to have remote links: https://github.com/aik099/phabricator/commit/51d8d510d4113ddd89f6113afd03321b87f747f8

Will tab panels be supported in future. Right now when panel is included as tab on tab panel, then clicking on tab will switch to that tab, which is correct.

Unfortunately changing the DiffusionSvnRawDiffQuery::executeQuery as I originally suspected might be wrong because for example the DiffusionCommitController::buildRawDiffResponse specifically passes path parameter that it expects diff to be built against.

Then I guess it's ready to be merged someday.

Just tried that and it doesn't render the same was as in regular diff (greyed out).

I can manually add missing new line message and see how it gots rendered.

The property text just is added to em tag an maybe nl2br is applied later. Since each property value is rendered in td the presence of br at the end won't really affect the output. So it's not lost, but in HTML tailing br and no br at the end of td content look the same.

Here are the changes we've discussed in D8478.

You can merge following change https://github.com/aik099/phabricator/commit/848a0a1c9574ac86399d3acc5b3b9afb1278fcb5 to your Phabricator fork to see if it works on your commits.

I'm done. Here is how it looks:

Are you sure? In the executed svn diff command the final argument would be svn://some.repo.com/sub-path/here if only sub-path/here is imported in a particular repository.

I completely agree with @aurelijus. @epriestley please revert this change.

@joshuaspence , the deprecated configuration options you've removed allowed to configure external linters, but now there is now to do it, e.g. specify standard for PHPCS linter. Maybe you should add support for these option in .arclint file instead?

Yes, it does.

@altendky , does doing svn up help? I saw this error a few times, when I've commited a sub-folder, but haven't done svn up afterwards to line up revisions of each top level folders in the working copy.

@aponomarenko could you please send a fix via Differential?

Another case, when this can be happening is during file/folder coping. Even through I can copy within the repository svn-subpath the revision reported by svn log as copyfrom-rev is last at the moment of copy per whole SVN repository and not just sub-path: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/repository/worker/commitchangeparser/PhabricatorRepositorySvnCommitChangeParserWorker.php;fa77fdd168d4f4f0a306e3b9867b5f09481fb6d1$50

@epriestley, could you please confirm that a described behavior is a bug?

@epriestley, could you please confirm that a described behavior is a bug? If that is a bug, then please take a look at the submitted fix.

It appears that during commit discovery on a repository (when daemon is looking for new commits) each commit wants to set it's own parent commit. And that parent commit is calculated as commitIdentifier -1 for SVN repositories. This is incorrect when we're dealing with SVN repositories, where only sub-path is imported.

@hach-que, were you able to move forward with implementation of what you've proposed?

I've added whitespace control for audits. It looks like this.

Thank you.

Some more info I was able to find out. The commits:

• have importStatus 15 (in contrast to 1039 for all other commits)
• have "foreign-svn-stub":true in repository_commitdata table in the commitDetails field

Thank you for explaining. I will consider not answering in IRC as No answer by default now.

• Repository was queried at / path and not sub-path

I've submitted a Differential Revision with a fix to described issue.

Solution:

1. if we're importing full SVN repository, then current implementation is correct
2. if we're importing sub-path only then we should do svn log svn://repo.url/sub/path --revision current_revision:1 --limit 1 command and get returned revision back

Digging even deeper I've found out that diffusion.commitparentsquery API call is used to determine commit parent. However it seems to work like this for SVN repositories: parent of this commit is this commit minus one: https://secure.phabricator.com/diffusion/P/browse/master/src/applications/diffusion/query/lowlevel/DiffusionLowLevelParentsQuery.php;120a7d91644753734bbdcdc7f8b50385829a0a5d$73

While debugging the issue I've figured out possible cause: in SVN the code, that detects previous commit on that file line somehow goes past sub-path of current repository (I wonder how this even possible) and commitIdentifier from another repository is found. When that commitIdentifier is combined with current repository callsign this results in bad commit.

We currently have built out infrastructure for US / Canada credit or debit cards.

firmly in the "the only value is educating aik099" category.

One task about letting admins log in as other users is philosophically something this project isn't about, so other than educating you directly its a pure loss.

@aik099 - consider making a donation - https://secure.phabricator.com/I2

Thanks for detailed explanation.

What a shame, I had pygments.enabled option set to false, which is default value. You can close this ticket now.

Pygments is installed (I've did yum install python-pygments.noarch and got answer back that package is installed)?

http://qa.in-portal.org/P1 - doesn't highlight.

Of course if Phabricator is used on an OpenSource project, then you're right @qgil.

I've got desired effect by adding my code into custom Harbormaster step, that I've attached through Herald to be executed on new commits, see T6518.

Not Phabricator as commit hook (specified via repository commit hook), but Phabricator instead of commit hook from repository. So, when Phabricator discovers a commit, then via Herald rule, that triggers Harbormaster build it, that via new build step, can notify Jenkins of that commit.

Proposed approach have several advantages over the classic trigger build HTTP request approach:

1. no need to create separate build, build step, herald rule for linking commit to build job for every repository under Phabricator, because all configuration happens on Jenkins side once per Job
2. configure herald rule, build, build step once for current and future repositories

If you want to offload your builds to Jenkins then you can, using the HTTP request mechanism that is already present. This mechanism works for any build server that accepts HTTP requests to start builds.

Harbormaster wins because it's more tightly integrated into Phabricator, but feature-wise it's really not a Jenkins.

In Jenkins job configuration you can set thresholds that will then mark build as:

• success
• unstable
• failure