Migrate VCS Systems?


#1

Is it possible to migrate VCS systems being able to maintain links between commit references and Maniphest tasks?

We’re in general looking to migrate from Mercurial to another VCS that exposes a Git interface (so from Phabricator’s perspective, it would be Hg->Git). I understand that likely all of our commit hashes will change, so if we use a rPROJECTa48fa9893af989829 reference in a Task/Phriction/soemwhere that will end up broken, but if we use commit messages with “Closes T933”, I would like that to still end up with a reference in T933.

Is it possible? I will likely try to experiment with this on a sandbox installation of Phabricator and some subset of the repository, but if right from the get go someone says “won’t work without first born sacrifices and a harvest moon” then I won’t bother.


#2

There’s a bunch of things that will just work, and a bunch of things than need a harvest moon to work.

Commit messages that have T123 or D441 in them will just work - the text gets interpreted as a link at run time (and in import time, to create a “matt mentioned this object” back-link.

If the commit message has a magic ref like “Closes T933”, it will work differently - when importing the new (back-ported) commit, the task is already closed, so it won’t be re-closed; The task will always say “closed by <hg commit>” and, later, “mentioned in <git commit>”.

Revisions that were closed by commits will likely still be “closed by <old commit>” forever, unless you want to do some db mangling.

When doing the porting, I think you can add the original hg hash to the new commit message, which Phabricator will then use to create a 2-way “mention” link between the old and and new commit, so you can navigate between them.


#3

Thanks for the response. There’s one clarification I’d like to make: when you write

The task will always say "closed by " and, later, "mentioned in ".

Do you mean that they will just say "closed by " without any revision identifier, or it will have a revision identifier, just pointing to the old revision?

And, along these lines, does this mean that I should keep the Hg repo a part of Phabricator? I was hoping to just drop the old Hg repo altogether, but I realize now that might be much more involved (which still might be worth it).


#4

Currently, your tasks should have something like this, if you put fixes T123 in some commit message:


Where the commit “monogram” is rHGPROJECThashcode.

After migrating, you’re just creating new commit that has the same message, but the task is already closed, so it would say something like:


with commit monogram of rGITPROJECThashcode.

The “closed by” event will not be deleted, it will remain there.

If you delete the old HG repository, links to its commits will actually keep working, because most of the meta-data is loaded to the database when importing a commit. The actual commit content/diff is not, so you’ll get some of the commit page, with a note saying “This commit has been deleted” instead of the diff information.
This will continue working commit links that are created by the system (like transactions), which use PHIDs instead of commit hash. It should also keep working for commit hashes entered manually into any remarkup field - the lookup is done in mysql.

You can also delete the repository and then remove the data from mysql using ./bin/remove destroy, but that will make all the links behave funny and you should not do that.

It is technically possible to update all the refs from old commits to new ones, by directly manipulating the database, but I doubt it actually worth the trouble.


#5

Perfect, thank you for the information, that helps a lot.