- User Since
- Dec 19 2013, 3:16 PM (336 w, 3 d)
Oct 13 2016
Feb 28 2016
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.
Jan 5 2016
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.
Dec 24 2015
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:
Dec 17 2015
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.
Dec 16 2015
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.
Nov 10 2015
Oct 26 2015
Jul 21 2015
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.
Jul 17 2015
Dec 15 2014
Other than D8478 prefixing a '\', the latter looks the same... aka, wrong. :]
Dec 12 2014
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.
Dec 10 2014
Nov 3 2014
Oct 6 2014
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.
Sep 23 2014
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.
Sep 22 2014
Aug 10 2014
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.
Aug 7 2014
Actually correct 'Only variables should be passed by reference' warning
Correct 'Only variables should be passed by reference' warning
Update for renamed file
May 17 2014
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.
Mar 25 2014
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
Mar 24 2014
Get all SVN properties for a revision at once
Mar 14 2014
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
Mar 10 2014
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. :]
Feb 19 2014
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... :[