In T7471#100638, @zzh wrote:

And the Subversion server is install over other machine, I'm not the administrator

I'm seeing this on the current version in my environment also. As oyvindselbek mentioned, everything seems to be working (updates are happening) except for the cleanup of the temp files.

And further, it seems to work fine as the web user.

Ok, I'll see if I can get a test case with LinesOfALargeExecFuture that reproduces it.

Hmm, I'm not sure then. It doesn't look like it's producing that much output, either ("... (10,110 more bytes) ..."), so I can't imagine it's any sort of resource exhaustion or OOM-killer kind of issue.

Seems to work fine.

Seems to work here: rHGTEST0e1f30ecdecaf66a3da45a62b7c6af3ad7c5515a

I think the HGTEST repo works now.

I think this is fixed now. In particular, the behavior today would be:

Does this command work properly when run from /var/repo/XYZ, where 'XYZ' is the repository callsign?

One possibility here is to reopen a Maniphest task if a "fixes" commit is reverted. I'm not sure whether this behavior is desirable.

There is no relevant "explain why" link because there is no transaction for someone added a commit: rPPfd5a74ad3fa1 on D19839 or someone added a differential revision: D19839 on rPPfd5a74ad3fa1.

Does clicking "Explain Why" explain why?

After updating yesterday to check out changes with T7100, we started seeing this issue when creating a new hosted mercurial repository. After updating for this task, the hosted repository no longer shows this error.

If we return rule as follows

Example working hgrc:

I have no immediate desire for the branches listing to resemble hg branches, I was just confused at the difference in output. I didn't realize the closed branches had multiple heads in my own repository :).

I think hg branches just picks one head to show when there are multiple heads of a branch. For example, if you're on rev 9 and hg up 8, then make a commit (creating a second local branch head for default), the hg branches command still shows only one head, even though your working copy has multiple open heads of the branch.

Yes they all show under hg heads -c as well. Looks like everything is set then as apparently there are multiple heads for the same branches, but all closed.

I'm guessing hg heads -c will also show them.

Yes it lists all the ones phabricator shows.

Does hg log --rev 'head()' give you the other heads?

Our repo has 4 closed branches and 1 open (being 'default'). The main repo page no longer shows the closed branches, but when viewing all branches, it looks like several are listed twice with different repo heads.

[cspeck@repo MS]$ hg branches -c
default                    93616:fade3df180a2
mim_4.2.0                  88329:eed05955c3cc (closed)
mim4x_trunk                88328:4dad86161093 (closed)
mim_4.1.0                  88325:02073e640fc3 (closed)
mv_1.1.0                   88324:d6e2fa29ad23 (closed)

I think this is in mostly reasonable shape now, but let us know if there are still issues.

D12549 applies the strategy recursively, although we'll probably hit shell argument length limits before we hit 65K branch heads.

This is rooted in a limitation with Mercurial. I've filed a report upstream:

The change breaks "Track Only", breaks repositories without "Track Only", breaks new imports, runs 75x slower than necessary in the cases above, etc.

Thanks for implementing this! I will definitely make use of this feature.

Global "Commit" rules in Herald can now add or remove projects, so you could write a rule like this:

It would be fantastic to get a view of Diffusion diff's with id and title between builds, to hand to QA with each testable build.

This was intentionally "kicked down the road" as an example of unhandled exceptions generally not being handled so well. See https://secure.phabricator.com/D11789#114084

In Git, we get fairly good control over error messages, although less so in Subversion/Mercurial. We emit this particular message ourselves:

Ah, okay. We call things applications here so its the "Diffusion application" or you can just say Diffusion.

Create a bot User that has Access to a Repository but not to Diffusion. Try to clone which will fail.

Isn't this a problem with Docker? ("Diffusion module" is some Docker thing of organizing Phabricator?)

Damn you and your psychic powers!

~~ psychic powers ~~

whoops

It did :/ thats random (would not have thought of that)

Restart apache or php-fpm and let me know if that fixes it?

Well that was fast... And sounds perfect. Thanks!

You can configure branch-level protection by allowing dangerous changes and then writing a Herald rule to protect specific branches. For example:

This appears to solve the problem for me, though Phabricator appears to ignore the 'Track Only' setting and instead imports all hundred or so branches; I don't know if that's at all related to @Jaraill's change though. And I'm also running into T7100.

We can prioritize this immediately, I'll follow up in a private thread.

We'd like this to be done soon as well. People have been complaining about using callsigns.

This will be a very good feature to have considering Github can allow you to do it.