I've got a Mercurial database that I want to migrate to Perforce and preserve all the changes. Tell me a way I can do this.
Update Mar/2013:
Just to make the informations up to date:
svn -> p4
There is a new tool called p4convert-svn:
p4convert-svn doc
Beware of filesystem case in/sensitivity.
hg -> p4
Following tool is not mentioned a lot, but it's recommended by perforce support:
hg convert p4 sink depot
It adds p4 sink into hg convert extension. Disadvantage is that it fits in mercurial 1.7.3 which is a bit outdated as of today (current is 2.2.5). It can be merged by hand easily into 2.0.2 version which may be sufficient even for largefile extension users.
For more information read file Readme-P4.txt in the depot.
One way that I thought of doing this is to clone the repository into my workspace and execute a python script to do the migration. The script would loop through each revision starting with 0 and ending with the tip, checking in files to p4 along the way.
I figure that I can get all the changeset comments via the log command, then I can use hg log -r i --template {rev}: {file_adds}|{file_dels}|{file_mods}\n, where i is the current revision, to get the files that were added, removed, renamed, etc. When I notice that I'm on a new branch, I can check for the branch in P4 and create it if necessary.
At the end of the day, all that stuff should be checked in accordingly to P4.
Take a look at the Perforce section of the Mercurial wiki page on Converting Repositories. There seems to be support for pushing changes from Mercurial to Perforce.
I have recently started researching how to migrate an Alienbrain repository to Perforce. As there are no tools publicity available to do this, my research had lead to several resources on how to write your migration program.
Read the "Migration Planning Guide" on the Perforce website (pdf link). The document is written for ClearCase to Perforce, however the three approaches are still relevant. In particular, have a look at the "Baseline Branch Import" technique to see if that would make sense for you.
Download a copy of svn2p4sync from Tigris (link) as it is one of the most tested migration scripts available. Whilst on the Tigris site, read the svn2p4sync release notes/issues page for a good history of how the script was developed (link).
I've also just found the Generic Conversion page (link) on the Mercurial wiki (thanks to the link in Wim Coenen answer).
Edit: for your specific case where there is a script, I would recommend you use the linked in Wim Coenen answer (link).
HTH,
Related
[NOTE: "Perfarce" is the name of a Mercurial extension for integrating with Perforce: https://www.mercurial-scm.org/wiki/PerfarceExtension]
We're starting to evaluate Mercurial for a project that's currently stored in Perforce. Rather than abandon the P4 depot and make all changes in Hg, we'd like to primarily work in Hg and push changes to P4 periodically. There's a chance some developers will continue working in Perforce during this evaluation, but other than that we want to evaluate the workflows that DVCS makes possible such as pulling from one dev's repo to another.
I've tried the Perfarce extension, and it looks like a great way to use Hg as an advanced P4 client with more granular local history. However, when I use Perfarce to check out the same tree on two different machines, I get two Mercurial histories with different changeset IDs. It looks like the only way to share changes this way would be to go through the P4 depot.
Are there other options for keeping developers' repositories synced with P4 without making them incompatible at the Mercurial level?
Honestly - this sounds like a situation that can be the cause for nightmares. Here is how I would approach it to minimize some of the risk and pain:
Setup the Perforce workspaces to "allwrite" such that Perforce won't interfere with Hg as much.
Use a single P4 workspace to sync changes from the depot down to a mercurial repository (and from hg back to the depot), then do your mercurial push/pull work from it. Treat it kind of like the master repository on GitHub or Bitbucket.
Using the one-true-workspace sync changes back to Perforce by using the "reconcile offline work" feature of P4V and make sure to carefully review the changelists (you don't want to submit the .hg directory).
With some discipline you should be able to avoid some pitfalls, though it certainly isn't an ideal path forward. I don't think there is a single bullet that will allow you to seamlessly keep your changes properly mirrored across all the different repositories and allow everyone to just work as usual.
I was wondering if Crucible can handle the following scenario with Mercurial.
How do you use DVCSs with Crucible in such a scenario?
There are several issues in a project, for each issue a developer makes a clone of the project from repo "stable-build", to repo "dev-0001" (on a local sharing server).
Clone is named according to the issue : "dev-0001" for example.
Now from there a developer clones on his local machine into clone "local-dev-0001", makes the changes and then pushes to "dev-0001".
Some other developer wants to review the changes in repo "dev-0001" before the dev that implemented 0001 can push to "stable-build".
What I tried is to set up Crucible for a repo (a separate test clone "test-crucible" directly from "stable-build". It took a loong time on a very power full machine, about 5 days.
My question is : how can Crucible and Mercurial be set up so that one can create reviews for the "dev-0001" clone befor eit is pushed to a somewhat central server, withouth waiting 5 days for Crucible to parse the "dev-0001" repo from the start, and maybe use the information of it's parent ? Is this already done does it need some sort of plugin?
I can offer more clarity for the scenario if that was a bit hazzy,
Thanks
I think I'm discovering the answer might be no for this workflow without altering it. Also found this for who is searching the answer for this :
https://answers.atlassian.com/questions/8798/does-latest-version-support-revieiwing-from-local-repositories-using-mercurial
I think I found out a satisfactory answer for my case, a pre-commit patch file could be used,
obtained from making a diff in "dev-0001" before pushing to "stable-build" with : "hg outgoing -p > patch-0001"
I commited (not pushed) a lot of files locally (including binary files removing & adding...) and now when I try to push it takes a lot of time. Actually I messed up my local repo history.
How could I avoid this mistake in the future ? Can I transform a set of local revision 1->2->3->4 to 1->2 with 2 being the final revision of the local clone ?
edit: since I was in hurry I started a new remote repo from scratch with revision 4. In the future I will go with the marked answer as it seems easier but I will dig other solutions to see the truth. Thx for your support.
It's not clear from your question whether those changes got pushed. If they're still local, you can more or less get rid of them easily. convert is one option. You can also use MQ (mercurial queues). Check the EditingHistory wiki article for a detailed explanation. It recommends MQ being the simplest approach.
To prevent that kind of mistakes, you should probably add a hook to reject 'bad' commits, given that you can describe them programatically ;)
Mercurial history is immutable, you can't delete using the normal tools. You can, however, create a new repo without those files:
$ hg clone -r 1 repo-with-too-much new-repo
that takes only revisions zero and one from the old repo and puts them into a new repo. Now copy the files from revision four into the new repo and commit.
This gets rid of those interstitial changesets, but any repo you have out there in the wild still has them, so when you pull you'll get them back.
In general once you've pushed a changeset it's out there and unless you can get everyone with a clone to delete it and reclone you're out of luck.
I'd like to evaluate Mercurial for my working projects. But most of my projects very heavily rely on the presence of svn:externals-like support. I've searched over StackOverflow and googled for corresponding support in Mercurial. All I found is subrepo feature added in Mercurial 1.3, but the page for this feature said:
subrepos are an experimental feature for Mercurial 1.3. So don't do this on mission critical repositories!
I don't want to use something unstable.
Can anybody shed some light on the real status of this feature, and the plans of polishing/finishing it and when it will be called "stable" and ready for mission critical repositories?
The word in the #mercurial IRC channel is that subrepos will continue to work as they do, and support will grow. For example currently the 'hg status' command isn't subrepo aware -- it works, it just doesn't recurse, but that in the future it will be. However, the current behaviors, fileformats (.hgsub and .hgsubstate) will only be changed in backward compatible ways.
So, go ahead and count on it now, and look forward to it getting better.
P.S. As of mercurial 1.4.2 the subrepos can now be subversion repos, so you can use a mercurial parent and a svn kid.
I've had good luck with the feature in my (light) usage of it so far. It's come in handy in two places:
Backing up a tree of unrelated repositories with a single hg pull command.
Tying a project together with specific versions of its dependencies, so that a single hg clone gets buildable source code. This is closer to the typical svn:externals usage.
Here are a couple of the limitations I've seen with it so far:
In case #1 above, you have to commit all subrepos at once. This is only occasionally annoying, as Mercurial (like any DVCS) encourages frequent commits—so most repos aren't left sitting around in an incomplete state to begin with.
Only the most basic Mercurial commands are subrepo-aware: clone, push / pull, update / commit, and perhaps a couple of others.
Extension authors are going to need time to test their extensions against repositories with subrepos.
When the Mercurial team describes the feature as "experimental," they don't mean that it's suddenly going to decide to erase all your data. They just mean that they haven't coded around all the edge cases like name conflicts (e.g., one developer adds a subrepo called README, while another developer adds a text file called README).
I have a project that is combining multiple hg repositories (different components) to build a single application. I'm looking for a cross-platform tool to support performing an operation on multiple repos at the same time (e.g. tag, pull, push, commit etc...) Essentially, I'm looking for the 'repo' script that Google wrote for Android, but for hg instead of git:
http://source.android.com/download/using-repo
I searched on stack overflow and found this:
mercurial windows batch file for pulling changes to multiple repositories
But it's still a bit manual and windows only. I know it's not that hard to write the script to either pass a command to the repos or try to encapsulate everything, but thought that it might be a common thing so maybe others already have a solution. I suppose one approach would be to port the repo script to hg (find and replace git with hg would probably get pretty far for simple operations).
What do other people do in this situation?
Definitely look at the new (in version 1.3) subrepositories feature in Mercurial. It lets you have an overarching repository that contains other repositories. The state of the top level includes a file that specifies the hash of the tip of the sub-repos, so you can effectively specify a single hash node id that encompasses the state of all the subordinate repos.
https://www.mercurial-scm.org/wiki/subrepos
I have been in a similar scenario for the past year, working daily with a project spread over 6 repositories, and being the one responsible for most branching/merging stuff etc.
At some point I found a simple bash-script for checking multiple SVN repo's. I adoptet it to Mercurial and have extended it over time. Right now I can't recall or google the original source of the script, so I unfortunately can't credit the original author (will credit in my script if I find the info later).
My "hgall" script is published on GitHub at https://github.com/JKrag/hgall
It is made for my own use, and thus directly references a few extensions that I have been using, but this can been easily edited out. (or just don't use the commands that call extensions you haven't installed).
The script is documented in the README, including my personal "tweak" of having it (by default) ignore repo's that start with underscore, as I use these as temporary clones to test messy operations (e.g. large merges).
I hope this script is useful to some of you - it has been of great help to me over the last year. Our company has just moved to Git, so I will probably not be making many updates in the near future, but might possibly be porting it to Git some day....
Additionally, Iain Lowe has an extension https://bitbucket.org/ilowe/multirepo/src which can manage multiple repositories.