Yes, I'm using svn:externals from same repository. I have several base modules stored in repository and projects include these base modules via externals.

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.

@altendky, when doing svn up the revision for each file in working copy is set to last commit in the repository in general, not last commit when each particular path was changed. This solved problem for me at least when using Subversion 1.6 client.

@nnnn20430: I see, thank you for clarification. I will give that a try.

Maybe IndexEngine is a better name than FulltextEngine.

Upshot is that this seems very promising to me. I think the pathway forward here is something like:

Okay, here's a query script:

I created an ngrams table like this:

Try the dedicated table on the files dataset and see how happy MySQL is about that (if it's better but still not great, we might still do this in conjunction with bigrams/trigrams).

I miss the Clowncopterize button too, but wouldn't something like "Nitpick" be more in line with the Differential?

There is a small possibility that D14801 fixed this. That's highly speculative, but it is the kind of low-level bug which could theoretically cause intermittent, difficult-to-reproduce hangs of this nature.

They can now be sorted by custom fields, and after T4863 they'll be able to render in lists. It's possible that T9372 will impact this, too.

Reading Custom Fields is now supported in new *.search endpoints (paste.search, maniphest.search, owners.search).

Temporary workaround to get a change like this into a client:

The maniphest.search endpoint at HEAD now has full-power ordering controls.

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.

Is it an happy 10 thousands tasks party ?

Noting here, this started happening again within the past day or two. I'm going to cancel the leased tasks again, but would like to find some way to determine what's going on. I suspect there might be some diff's that are no longer around (not sure how) which are causing this. Will grep through the daemon logs at some point.

I removed "Quick Create" entirely in T9905, so this is obsolete (at least, for now).

In T9905#148799, @avivey wrote:

Editing tasks via the editor now also subscribes me to them (eg https://secure.phabricator.com/T3277#148797); I don't think that's intended?

Not sure if trolling...

The "Can Edit Task Status" thing is now covered in T10003. I'm going to spin the remaining errata out into a followup since most of this chatter is now obsolete.

Here's a tentative plan for this:

There's no IconSetEditField yet but we don't need to keep this waiting on that.

Ah, it looks like we need to "Unsubscribe" from that project - seems like a reasonable compromise. Thanks!

I have gone for this approach, but now I get emails from every single update to every single diff (as I am a member of Engineering) - is there a way to squelch these?

Confirmed via IRC:

For example, there are reasonable cases where non-engineers could be review code, like changes to copy.

Is this actively happening? The request sounds hypothetical. In general engineers should know who to send reviews to and only land via reasonable sources of review (like other engineers, and not pms).

The new *.edit and *.search endpoints are now available in Paste and Maniphest, so arc paste, arc todo, and arc tasks can switch over. I'm not necessarily planning to do this immediately -- at a minimum, I'm going to let them stabilize a bit first.

I think this stuff is basically in good shape, I'll follow up on the Phame stuff in T9897 and the arc stuff in T7715.

This does not describe a bug with the upstream. We do not have the resources to investigate or fix problems which begin with "apply <large amount of custom code>". See also T5447.

I don't have any current plans to build a mechanism like this.