I think I've got a small tidbit to add on a specific use-case with Jenkins. I had been using pipeline builds which are working nicely but I just tried to setup a multi-branch pipeline build and this requires the branch name in the Jenkins URL of the HTTP request triggering the build. I suspect in this case the proper thing to do would be to trigger and build twice. I guess that's more of an on-branch-change sort of situation than on-commit and using those triggers in Herald (they look to be present, I haven't used them) and having that information passed on to Harbormaster as mentioned could fill the need.

Thanks for the discussion and for improving the clarity of my request.

I do agree that commenting is usually done after reviewing the existing history. The concern expressed to me was that the extra navigational steps to get back to the workboard after commenting on a ticket were less pleasing than simply having a popover close. The only real reference I've got for this is that Trello allows viewing of the history and commenting within a popover... not that that is any justification unto itself.

Back at work... I have the same php, php-curl, and php-json versions in Cygwin and I am still core dumping (with my questionable-or-worse distribution system I'm not sure what arcanist and libphutil versions). I then updated to arcanist b3e68c9 and libphutil adb8a9c and arc doesn't seg-fault anymore. So, it seems to me that the initial trigger has likely been removed from arcanist but the issue that made it a seg-fault instead of a nice stack trace I suppose is still there in the PHP packages.

I have had this issue at work for awhile but I just happened to install fresh Cygwin at home and arcanist is working. I installed:

Yes, it is possible and that is what I am doing. :] You can point to an entire different server if you want, but we happen to have ^/../other_repo since the externals are on the same server.

Were you using externals? This is specifically about externals which can not be expected to have the same base revision since they are an entirely different repository.

Sorry @aik099, I guess I totally missed your question last year. In the example, the main repository is correctly listed at revision 203 and the external repository is listed at revision 154. They are separate repositories so it would only be by chance if they ever should be the same number. I will also mention that engine is actually an external of canopen which is an external of the main repository so my propget command isn't particularly relevant.

In T4207#141783, @d.maznekov wrote:

In T4207#127358, @altendky wrote:

In case anyone might find it useful I put up P1828. It's my first libphutil script so it's a bit messy and you have to hardcode some of your specific server and user info but so it goes. It generates remarkup-ready dot code with a graph of the specified project's ticket dependencies.

How can we use that?
Where to put that file and how to call it within web interface of Phab.

In case anyone might find it useful I put up P1828. It's my first libphutil script so it's a bit messy and you have to hardcode some of your specific server and user info but so it goes. It generates remarkup-ready dot code with a graph of the specified project's ticket dependencies.

Other than D8478 prefixing a '\', the latter looks the same... aka, wrong. :]

Sorry, this is all coming back to me more slowly than it should have. For the property, the output from my SVN diff-vs-0 calls were generating that message, not Phabricator.

I haven't run this myself but the only regression you have mentioned compared with D8478 is that [[D8478#98991 | there is no No newline at end of file warning]] (all the other points are rendering issues). While I do think it is more important to have this fix accepted, it does seem technically correct to avoid losing that non-EOL incidentally. Based on your example XML response from SVN I made a sample script and the presence and lack of EOL are certainly exhibited in the output of SimpleXML. I'm not quite sure where it's getting lost here but somehow was not in D8478.

The first time you commit a good (UTF-8) file it will still list as binary because the old side of the diff is binary. The second good commit will result in a good new and old version that can be text diff'ed. Also, pure ASCII is not needed, UTF-8 is fine so you should be able to use whatever characters you need for your native language.

I agree whole-heartedly with your comments about pre-commit review. We do some of that but mostly not. I am picking my battles and already fighting on too many fronts. Even audits are optional at best.

Thanks for the pointer. We do generally do this but would still like the catch-all for when we don't. Mostly I want to be able to go get a list of all commits which have not been accepted (or derived from an accepted revision) within some set restricted to certain paths in certain repositories (and since some time). Don't bug the entire team up front or whenever anybody comments on anything, but make it easy to get a list of things that need to be looked at.

@davisoa I've been running each revision of D8478 since I put it in. Admittedly with only internal use by three people but I haven't been noticing any issues.

Am I on the right track here? Is this of interest, or should I plan on maintaining it in a branch for myself? Thanks for your consideration.

Actually correct 'Only variables should be passed by reference' warning

Correct 'Only variables should be passed by reference' warning

Update for renamed file

I think this may be ready for another review? The security hazard should be removed and the existing diff parsing is being leveraged. Thanks for your time.

While trying to figure out how to get the properties with one fell swoop (SO it was suggested that SVN bindings could be better. Is there a particular reason that the SVN CLI was used instead?

(Actually) Get all SVN properties at once

Get all SVN properties for a revision at once

I saw the other code for parsing raw diffs after I put this together so I'll go look into using it. It does seem to have some ability to deal with the svn diff output for properties (which is included). My SVN server is extra slow so I will likely benefit even more than most from reducing the number of futures. I should also have mentioned the security hazard immediately so I wouldn't forget it. Thanks for being sure to bring it back up for me.

Remove .local copy

Correct variable names to underscore_format

This could also become a foreach (array('old', 'new') as $age) loop. It is very repetitive as it is now.

After completing this (my first contribution attempt) I looked around again with a little more comfort and familiarity and it seems this whole function may be a bit backwards. It fetches the entire source for both new and old and then creates a diff from that. I added fetching of new and old properties as well. I think there is code in ArcanistDiffParser.php that may actually parse a raw SVN diff which would make this a whole lot simpler and faster... but this at least seems to work for my cases and I need to work on work stuff tomorrow. :]

Phabricator expects all text to be in UTF-8 (according to TFM), so I assumed that was the cause. I believe I used iconv but it appears recode may be better? I'm thinking I did it incorrectly and probably actually took it down to pure ASCII... :[