That will cause problems.

Trying to cheat by having Phabricator configured to host the repository, and then make changes outside of Phabricator's control will cause trouble:

• Phabricator will not be aware of new commits and branch changes (It won't know to look for them)
• File permissions will cause trouble (Phabricator expects to be able to write to its storage)
• It will not save you any work (You still need to setup all repositories in Phabricator)

You can also not import a repository via local path (file://), for security concerns; You'd have to go via the ssh:// or https:// protocols already in place.

We run mercurial repositories hosted over SSH on internal network, and run Phabricator on a separate server. After the initial import, Phabricator stays in-sync with the repositories by regularly pulling updates. It does this because we have all of the repositories on Phabricator configured as "Host Repository Elsewhere", so the SSH hosting we had setup previously with push hooks remains the same -- all developers continue to push/pull from this existing location.

This setup is very convenient as only developers who are looking to use Phabricator need to know about it -- any developer/team that doesn't want to use it does not need to and their workflow has not been impacted.

The Phabricator server (currently) never pushes to the hosted repository -- all its data is stored in the MySQL database (and some files on disk), so it would not have any "data loss" effects as the repository is hosted on a different server.

We have ~50-100 repositories, with just a few being the primary and the majority being personal forks. We have around 20 of them imported into Phabricator. After ~8 months of having a Phabricator instance running the only issues we've run into with regards to repositories have been problems due to Mercurial's largefiles being turned on -- which is not strictly a Phabricator issue.