Awesome, thanks!

I have a 500mb repo somewhere, and it would reproduce very easily to me, so I'll test this.

After D15427, this should be pretty clear for "Land Revision".

Importing SVN repositories as single repositories is recommended (Facebook's had several million commits in 2011, IIRC).

This hasn't happened again and I think it's less reasonable to expect it to work in modern Phabricator.

I think this was resolved at some point -- this is the behavior at HEAD, which seems broadly reasonable:

This was fixed a couple of years ago in D4730, and works fine on the modern LLVM install: http://reviews.llvm.org/rL170845

After D15424, arc fails when failing to push the staging area.

I've marked D15424 as fixing this, although I don't have a detailed understanding of exactly what goes on in the git protocol and which heuristics it is using. In particular, I haven't been able to trick it into doing too much work locally (maybe it also looks at parents?).

This is on a daily cron, I think you missed the update by a couple of hours. Link works OK for me now.

Hi! How can we reproduce this behavior?

Ah, makes sense.

That's because the symbols db on this install aren't always up-to-date; utils.php was updated recently, but the db still points to the old location...

Thanks for the report! This was a bug.

Yeah, that claim assumes someone will arc diff some published commit sooner or later (i.e., run arc diff while on master with no local changes). While this wouldn't happen on a normal workflow or on purpose, I suspect it happens more-often-than-never.

From what I see, this doesn't actually normalize over time, if the staging repo is used only for staging: none of the /diff/ refs will ever be a parent of master from the real repo, because of the rebase during arc-land (I've written this at some point in Manual Staging Area Caveat).

Yes, this should eliminate the need to sync/cron/do anything.

Would this eliminate most of the benefit from cron based "sync refs from the main repo" glue?

Unfortunately, this bug is reproducible on my installation by simply visiting the Diffusion URL, there are no other steps.

I did look at the page.

We're also about to select a source code hosting / project management tool, and Phabricator looks awesome but git-lfs support is a requirement for us!

This has been open for several months without forward progress.

See Contributing Bug Reports for what we look for in a bug report. Specifically we need steps to reproduce the issue. If you're not sure if its a bug or other issue, and don't have steps to reproduce, please use the other Community Resources available for help.

I am solving this problem. Reason was in empty Callsign in setting repository. After I added callsing, revisions became openable for audits.

i am cloning repo in my local phabricator(ssh only read) and cloning repo in my notebook, then add new file in dir1 "test" and commit he in rSVNTEST then accept commit and i found this revision on my local phabricator where she all the same do not open for review code same all post revisions...

okey im trying pull test repo in my sandbox, but im not sure what it's working. Chad how you can see on offer connect in my local phabricator and see all your self ? :)

We're also not familiar with https://riouxsvn.com/, so maybe removing that host as a variable would help. Phabricator has built in SVN hosting.

Unfortunately no, we need reproduction steps to be able to move further. We need some means of observing the issue in a local sandbox so we can be sure we've found and fixed the right bug. That might mean you isolating the offending commit that is giving Phabricator trouble, breaking down to a minimal test case, and pushing an example to rSVNTEST for us to inspect.

chad you have any ideas what's wrong in my local phabricator or whath next steps i have to do for resove it's problem?

I guess "off" is default, so "disabled" isn't quite accurate.

@epriestley, test files in last comment indicate 31 can decompress gzip properly.
please check it.

Thanks for the heads up. I will contact my user with this information. What you said make totally sense to me :).

To be clear: I was trying to describe my problem, not ask for a specific solution. EditEngine for creation would help a lot but I was focused on editing. I guess T10337 would actually solve the issue, though not in the web UI.

Sorry, I'm still not sure I quite understand the specific use cases for this feature that you anticipate.

We have 2 distinct profiles and a few one-offs.
Ideally the following would be managed: Policies, Text Encoding, Branches, Actions. The remainder are templatized but obviously differ from repo to repo.

Do you legitimately have several distinct "profiles"? What differs between them?

Yes that should work for my use case - I've tested and verified this functionality. Thanks!

oh

This just sounds a lot like "I ran rm -rf /var/repo/X/ and all the data for rX vanished" to me, which is completely expected and should be predictable.

None of the repository replication code is even written, though. What behavior do you expect today?

When we migrate our repository hosting to Phabricator, I plan to setup multiple repository hosts for sufficient redundancy. In this case, I would expect the new hosts to clone the repositories from a read-only slave.

Suppose you have a hosted, active repository and do this:

Just a word to confirm the issue is solved in the new stable release.

Thanks! The moving of the host was I think my main point that clarified it for me.

The steps to reproduce are quite simple:

Well, specifically what you were doing, and what issues were caused after. Like moving tiers.

Ok, if you feel this is a bug report, can you list the steps to reproduce the core issue in the description?

If the repository is hosted elsewhere then Phabricator isn't the canonical source, and the other system would be responsible for data anyway.

The problem here is that things will mysteriously stop working. Let's say that I refer to rXabcdef in a comment and then later mark rX as archived and replace my repository tier. Anyone who later clicks on the rXabcdef reference will hit an error.

That's what I mean by "I must be missing something". What data is lost if it's hosted elsewhere?