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.

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.

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.

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.

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

@hach-que, were you about to develop Jenkins support in your fork or somewhere else?

Ah, I didn't knew that recent dates are shown in different format.

Unfortunately I use that key, so I can't upload it. I've chosen to use Private Key, that Phabricator generated for now. Feel free to close this task then.

It's ok, that format was changed. What I consider a bug, that different formats coexist in same list. If you do store parsed date format in DB, then why this wasn't fixed by a migration?

Before you've replied I've tried to implement this locally and I was very surprised when all demons at once picked up the work and PhabricatorRepositoryCommitParserWorker::doWork method was executed 5 times. Is this normal?

I start credential creation from repository editing screen. Maybe that matters. Here is the workflow:

1. Before you've replied I've tried to implement this locally and I was very surprised when all demons at once picked up the work and PhabricatorRepositoryCommitParserWorker::doWork method was executed 5 times. Is this normal?
2. There are no protection inside to prevent such things from happening, like daemon who wants to parse the commit locks that commit, which should prevent others from doing the same in parallel.
3. Is there other (non-event based) way to do custom code after commit is parsed? If so, then where this code should be placed?

Thanks.

Can storage adjust also create new/delete existing columns? For me it changed types of columns and changed collations, but nothing more.

It appears to be the case. I don't do git pull each day and the fix was commited yesterday :) You can safely close this then.

It worked, thanks.

It worked, thanks.

You mean to Firefox Browser bug tracker? I think not. The issue is specific to Firefox Mac version. Firefox latest + Firebug on Windows doesn't have that console.log issue.

Gladly I use Phabricator in Chrome, where it works as expected. I'm using Firefox for development only and that is how I've been able to see the issue in first place.

In other words if Firefox 34 is released, then it's OK if Phabricator will no longer look as designed in Firefox 33?

And these mailKeys cause document save exception, how so?

Maybe storage adjust was changing collation of columns without actually converting content inside them to use that new collation?

I've just verified that all existing documents before storage adjust are not editable, even if I just have "test" word in them. I can create new and edit these new documents without issues.

I create page some time ago. Then made storage adjustments recently and tried to edit page content and got that error. In fact if I even add one word at the end I'm getting that error.

Ah, now I get it after reading description of D10798. I shouldn't have executed storage adjustments, because that resulted in that exception in first place.

Is there anything wrong in the content I'm trying to save? I've executed all storage adjustments, so I shouldn't be getting this error at all.

On Windows 7 with same browser window size everything works. Maybe decreasing this number will help solve the problem:

The only place where custom fields aren't integrated now is Diffusion. While looking into ways how this can be done I've discovered, that both Branches and Tags custom fields aren't really used/stored at all, because branch/tag of each commit is retrieved directly from repository via ajax call when that commit is viewed.