Here you go: P1698

Note: A user reported receiving the same types of emails form this repo https://phabricator.wikimedia.org/diffusion/EVED/

@TiTi were you able to get around this issue?

Hi, This is a svn client problem. Update the svn client to 1.8x and it should work fine.

In T6887#90318, @chasemp wrote:

In T6887#90317, @epriestley wrote:

Is it possible that the affected repos are being imported by creating a new hosted repo and then pushing to it, versus using "Import existing repository"?

I don't think so but let's ask @WikiChad ?

Specifically, if you do that, the repo gets "imported" immediately and then the push is treated like new commits. We should probably fix/change that, but not sure if that's what is happening here.

In T6887#90317, @epriestley wrote:

Is it possible that the affected repos are being imported by creating a new hosted repo and then pushing to it, versus using "Import existing repository"?

Is it possible that the affected repos are being imported by creating a new hosted repo and then pushing to it, versus using "Import existing repository"?

side note, we've imported some other repo's like https://phabricator.wikimedia.org/diffusion/OPUP/ and I have personally never gotten an email for my historical activity. So it's some repos only? It has taken us a bit to find the common thread on this.

Yeah, sure. I'm going to assume you're at the root of an existing git repo with at least two commits.

My git foo is somewhat weak. Can you provide a sequence of git, text editing, and arc commands to reproduce this?

Yeay! Fixed it. So the end result is:

Yeah our main vibe on this is it's an environment issue, not a Phabricator issue. Though we are always up for improving our 'you has bad environment' checks.

OK, thanks for your help. In the last few minutes I found where the PHP errors logs go (I'm more a Ruby/Java person) and found these logs:

Sorry, I mean full access (ie, root). If this machine is at your company, it's not something we can help with. If you have a clean AWS image or something, we can poke around, but without an easy case for us to locally reproduce an issue, we have no means of fixing any issue.

Sure. I can open some firewall rules. But I'll send the URL to you privately if that's OK so every web crawler/hacker in the world doesn't have a go at it.

Can you provide access to an install that exhibits the problem?

Woah... as explained in a previous comment I've already done that. Twice now. First I upgraded to master from github (just read up a few comments). Then I dropped all the databases and started again from scratch.

I would generally recommend removing the packaged version of Phabricator and installing from our source directly. We have no means of quality control over third party sources and providing support as you can see, is difficult.

No. That works fine.

Does this server (secure.phabricator.com) give you the same error?

Yes, I get the error after I choose the "password" option in /passphrase/create. Same error as when doing the same thing from the diffusion application.

https://secure.phabricator.com/passphrase/create gives you an error? I have not been able to reproduce the error you are describing. Does it reproduce on this install? What, specifically, are the steps to reproducing it here?

How do I do that differently to what I described above? Is there some other place in the UI I go to?

Do you get the same error creating a Passphrase on this instance?

Can you suggest where I should look? Is this the relevant code:

Closed by commit rP204ae221d270.

We haven't seen other users having difficulty with this.

Note that I get the same result when I create a new credential from this URL:

https

What protocol does the repository use? For example, if the URL looks like "svn+ssh://example.com/repo", the protocol would be "svn+ssh".

I have upgraded to the current master from the github repository and run
all upgrade scripts. There is no difference in behaviour.

You should install Phabricator using the instructions under https://secure.phabricator.com/book/phabricator/article/installation_guide/#installing-required-comp as that FreeBSD Phabricator package isn't official (as per T4200).

我有测试了其他文件,不是必现的,发现有的文件有问题,而有的没有

I also encountered the same problem,Non-probabilistic problem when switching Blame state

Tenatively, the easiest fix for this might be to add a Lisk property attribute which stops it from updating the importStatus field during a normal save().

epriestley: Oh, I thiiink it might be a race condition.
epriestley: Yeah.
epriestley: Your commits are different from mine.
epriestley: So I think what's happening is:
epriestley: Process A is parsing the message for the commit which mentions the problematic commit. It loads a copy of the commit object.
epriestley: Process B is parsing the herald rules for the mentioned commit. It sets the "herald is done" flag.
epriestley: Process A writes the mention and saves the object, reverting the "herald is done" flag.

I went so far as to re-install Phabricator from scratch and was able to successfully fully import the Phabricator repository again.

Nah, this is just a nice-to-have some day. I haven't seen too many users hitting issues here recently.

Any rush on this / D10492? (There's an inline on D10492 I haven't addressed yet that's rigorous enough with regards to testing that I've been procrastinating...)

Closed by commit rP12c7c399ce14.

Closed by commit rP2fe553761ae7.

Possibly we should just prevent the daemons from launching if this isn't defined, although maybe that's too severe. We could look at that if more users run into trouble.

Specifically, one of the features that will be enabled is repository imports.

base_uri breaks lots of random things, which is why we ask you to set it (though some people use it fine without, in limited ability). The full setup message also states scripts and daemons will likely have issues.

The text shown in the unresolved setup issues was "The base URI for this install is not configured. Configuring it will improve security and enable features." - I would expect it to tell me that this needs to be set up before I can import a repository, not silently fail in the background.

We had no herald rules it was a clean start.

Yes, everything is fine. Just an FYI that importing the commits into Phabricator is done via the various worker parsing...

The issue is not to import the commits into phabricator. But when the workers start to parse the commits for "whatever". If you go to the deamons task list is everything fine ?

I do not know how to reproduce this issue as reported. For example, I import the Phabricator production instance into my local dev install. I do have a btrahan account there, but otherwise there is no user account overlap. Commits seem to import fine:

+1 on this one!
We have 100 odd closed feature branches that are clogging things up.

Thanks for getting this so fast, we'll be sure to pull this into our next deployment.

Closed by commit rP8ac73b2bf351.

I can only reproduce this by setting the Differential application to a restrictive policy such as administrators only. With default policy, uninstalling the Differential application does not reproduce this. Updated the task.

I peeped the IRC log so I'll take a stab at this now.

how to configure git repository in centos 6.6

I filed T6768 to eventually produce a cleaner fix for this issue; D10998 should work, it's just not very elegant.

Confirmed this is a duplicate of D10998

Perhaps I'm running into T6456?

I don't think so, I'm seeing this on every repo and I don't see any tracebacks in debug logs. The workers on this install have never processed a single task.