(I think that's also filed in T10767.)

I'd love folder shortcuts (for directories that only contain a single directory). Clicking through a few levels in various Java projects would be slightly more pleasant.

Have a most recently accessed repo list in there somewhere. Right now the order is always listed by most recently updated repo shows at the top. Maybe a additional column in there that shows most frequented repos? or maybe a "favorites" list for repos. A user can have access to many repos but not use them frequently, so pushing them towards the bottom.

In T12804#226290, @sascha-egerer wrote:

T8442 would help a lot for those "I have to many repositories"

GitHub, which has an omnibox

I find it really annoying how there isn't a real repository search (grep files) before you go click on "Browse". Generally speaking, search in Diffusion is very confusing with three different search fields in comparison to GitHub, which has an omnibox.

T8442 would help a lot for those "I have to many repositories"

(That said, GitHub does show an accurate count so who knows. Maybe the page is slow because they aren't doing anything stream-oriented. In this case, a directory with 3M files probably just crashes.)

I also suspect that GitHub compromises here for performance. If you look at a very large directory on GitHub, it shows only the first 1,000 files fairly slowly (page takes 1-2 seconds for me) with no pager, and a warning that the directory is too large:

The reason this isn't trivial is that we ask git, hg, or svn for a list of files, for example with git ls-tree.

yes I believe you have been coaxed into a clever trap -- and your predicament is of your own making!!!

This will help

I’ve been catfished.

Yeah I just realized this isn't a front end change, I got to trace it down to the source.

I'd offer assistance with testing mercurial on a large repository - but the largest repository I have doesn't have more than ~50 items per directory (that I'm aware of~), so I don't think it would hit the stress points you're looking for.

oh

👍

(Poems doesn't have an example of the first kind of directory, and I don't know of any offhand, but you could build one locally in a couple minutes I think.)

Offhand, I don't know if the kernel has directories with a lot of files in it or not -- like, Phabricator itself probably has only 1-2 directories with more than 100 files (resources/sql/autopatches/) and might have none with 100+ files and directories, so you could implement this wrong (pick the first 100 paths, then sort them by "directoryness") without there being any counterexamples in Phabricator. It's possible the kernel is the same.

Is poems the best example or do you have another suggestion? I can try the linux kernal.

Or, specifically, a list of files like this:

(That is, more than 100 non-directory files.)

I don't care too much.

@epriestley Do you care if I just flip this. The hypothesis being folders are clicked more than files, and having them first makes more sense for me, and in our case, brings them above the page fold currently for rP.

I'd probably pass on the preference, I think folders should just go first. My main observation here is if you instrumented clicks of folders vs. clicks of files, folders are probably chosen 2-1, my expectation here is that people have to dig down first, then open the file they were looking for.

Same here with a german umlaut ("ä") in the file name.

See Planning for information on timelines and priorities.

Just curious if there is any news on this front?

Yeah I just didn't want to add the (...) view to DiffusionHistory if it's going to slow those pages down. I'd just leave the feature out.

I think using a Pool (like HandlePool) is not too much more work (at least, if I'm implementing it) than AJAX it and will be useful in more cases. I believe we need the Pool implementation regardless, sooner or later.

@epriestley maybe this should just AJAX?

😢

hahaha

Does it at least tell you how fast you're going?

Not sure if this is the correct ticket for it, but I got here via D13020.

In T5698#223992, @chad wrote:

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

Oh hai Cura uses Phabricator? I have a Lulzbot at home!

@Krinkle, @pablocarrillo I second your requests. Great suggestion. I have a large README.md that I would love to split into multiple documentation files, without losing all the formatting.

When using Mercurial, can Diffusion handle multiple remote bookmarks on the same branch?

Yes, this will be implemented.

Is there any chance this will ever get implemented? The lack of this feature makes our lives a lot harder, and it's a highly ubiquitous feature (GitLab, GitHub, BitBucket, Gerrit, etc. all have it). We're trying to modernize a very old codebase, and any time anybody auto-formats a file to match our standard, Phabricator's diffs become completely useless. This wouldn't be a problem if we were using any other tool.

Any idea of how to do this on CentOs?

• I deployed D17774 to secure.
• I verified that rSVNTEST now correctly raised an error because it was backed by a service with muliple hosts.
• I moved rSVNTEST and rHGTEST to a one-host service, securex-legacy.phacility.net.
• I can no longer reproduce any issues against this host.

Problems do not reproduce when downgrading svn client:

https://secure.phabricator.com/rSVNTEST10

Please use Conphernce or Ponder if you have questions about Phabricator.

fails for my MacBook:

Thank you for replay.
Umm..., Reproduce with the same procedure on my environment.
It may depend on the client environment.

I'm just going to merge this into T11401, at least for the moment. That may eventually split out into application-specific tasks when it gets underway.

I can't reproduce this:

I agree, pagination way below the fold is rather inconspicuous

hahaha, thanks... really easy to miss those

Bystander input: try page 3: https://phabricator.kde.org/source/krita/browse/master/libs/ui/?offset=200

(I assumed it was a keydown vs keypress vs whatever event sort of thing but haven't actually looked into it.)

Yeah, this bites me half the time too.

When I trying to update the hosted repository from the remote GIT installed location. It is throwing following error message:
Error updating working copy: Command failed with error #255!
COMMAND
git fetch origin '+refs/*:refs/*' --prune

It helps to resolve my issue also.

Recent security issues in GitHub, GitLab, etc., with markdown:

Totally my fault, I just didn't read half that sentence. 🐈

Thanks for looking into this so quickly.

And thanks for the report! Let us know if you run into anything else.