https://secure.phabricator.com/conduit/method/repository.create/ is the conduit call to create a new remote-tracking repository (There used to be a separate Repository "application", hence the name).

Is your server out of memory? Also, what is your PHP's memory limit set to?

Just throwing my +1, agreeing with the stuff in T4694 and wanting a way to remove the need for call signs.

Here's the best link I could find...

Thanks holmboe! I think we got exactly the same issue. But is there a chance that the svn hosting used to be correct, and broke by any of the recent versions?

Alrighty folks - after your next upgrade this should be completely resolved.

In CentOS "yum install mercurial" installs version 1.4 by default

You're running Mercurial 1.4, which is about 5 years old (released Nov, 2009). Update to a modern version of Mercurial.

On the phabricator box:

Can you run this command on your server and show us the output?

what environment information can you provide?

what do you mean by "doing update from Mercurial" ...?

Go to Phabricator=>Diffusion=>Select Mercurial Repository=>Edit Repository=>click "update Now"

"I’m getting following error when doing update from Mercurial"

Need a way to add tokens to comments. :)

So maybe just reconsidering the location of this in the UI would help?

I think we're going to convert this to "Recent Pending Differential Revisions" at a minimum, and only show stuff updated in the last couple of weeks. That should help with some cases of this, although not the specific case mentioned here (see T5658).

D10800 will resolve the last known bits here. Will close when it lands.

btw, found another such case in our history pushed by @thoughtpolice

In T6483#82485, @chad wrote:

I don't recall all the history here, but I seem to recall --signoff was a feature added to git for reviewing linux kernel patches.

Does this reproduce at all?

Hrrm, I would have expected this to associate. We did some work here recently (T5693 / T3686) on the Differential side ("Why did this associate?") but don't currently expose a link on the Diffusion side to see the other half of the story ("Why didn't this associate?").

I don't recall all the history here, but I seem to recall --signoff was a feature added to git for reviewing linux kernel patches.

Great, big thanks.

I understand. Then please tell me one thing (I hope that's not complex): how to determine which controller have processed an url?

Sorry, the answers to those questions are very complex and I don't have time to walk you through it since we aren't interested in bringing this upstream.

@epriestley , if I'm about to implement this in my local fork, could you please tell me:

Maybe you can do as Atlassian FishEye did: for each repository defined a regex to determine trunk/branch/tag (3 separate regexps). Then we can match path of 1st file in commit (hopefully nobody will do cross-branch/tag commits) and detect branch/tag.

We don't plan to support inferring branches and tags from directory structure conventions in SVN.

As we've already discussed that task is far from it's implementation. Until then current API call works, why mark it as deprecated and prevent anybody willing to add comment to commit from seeing that call on /conduit/ page. I guess deprecation status only affects visibility of that API call, but it still continues to work.

See T5873.

I don't think this is worth pursuing currently, given work involved.

+1 from me.

T6426 is a specific complaint about the differences here, asking for the file count to be surfaced consistently.

Some specific notes on this:

This seems pretty funky to me versus something like T6008 where you could just edit the code as you go, achieving the goal of easily adding "TODO" comments all over the code. I also think the amount of people browsing the code via diffusion versus looking at the actual code itself is such that you're much better off with the comments actually being part of the code. I also had my first waking nightmare about the user confusion as these comments pop up in Differential / Audit views versus something like T6008 where they'd be there in the code itself in a rather sensical fashion.

Luckily the existing repos, that are configured with file:// protocol are still working. I hope you won't be removing that.

We removed this in June for security reasons. You can find some discussion in the June changelog:

T6395 identified a new stack trace for empty commits.

Audit previously ran older code that was inconsistent with how every other application works. That had been fixed and new user preferences were added in support. We don't have any plans to offer admins additional defaults to set for users (are there any?). Event listeners already exist for things like registration and are infinitly more flexible.

Not sure I understand what you mean by saying it's running on modern infrastructure?

Audit is now running on modern infrastructure and is consistent will all other Phabricator applications.

Don't think so, I just added them using the LDAP import page, and they work as normal accounts for people who need to do something in phabricator.

Are these disabled accounts receiving the email?

I can't reproduce this, but we'll keep an eye on it.

/tmp being full probably doesn't apply to me, since i don't have a special mount-point for it, so it should be sharing in the bounty of ~28GB of free space on /dev/sda1. Someone did pull the plug on the machine, but that was probably about half a year ago, and I haven't noticed these errors until just now.

Yeah, I think publishing feed stories and sending emails from importing repositories is badsauce. Patch in a moment.

Incidentally, I just imported another repository, which resulted in the feed receiving a bunch of commit messages and one of the other developers on that repository receiving a ton of e-mails (I received nothing, although I also have a few commits in that repository).

Will do.

Yeah, this is something with MySQL and not really directly related to Phabricator. I'd try:

Alrighty folks - if you are still impacted by this, could you please update, restart daemons, and then run

(rPfda0b086b565aab6f8486ac5a57585320d63f16d is the commit in question that is barfing with the character encoding problem for me.)