I have been migrating from subversion to mercurial piecemeal and this has created a bit of a tangle. I had an old SVN server (pre 1.4) to start with so here is what happened.
HgSubversion did not want to pull in the full history from trunk, so I did a shallow convert.
My colleagues did their last commits to SVN and I pulled those into Hg.
We moved over to Hg and started pushing to it
Just to be safe one of my colleagues made some more commits to SVN.
I managed upgrade the SVN server and get the full repo to the new SVN.
HgSubversion pulled in the full history successfully - including the few extra/duplicate commits.
Now I would like to "transplant" the commits in the shallow mercurial repository into the full history, the repositories are related in content but unrelated in mercurial hashes.Short of just copy pasting content what would be the best way to migrate the changes ? Eventually everybody should be able:
To switch the Hg repo with full history and keep working
Have automated push from the Hg repos of suitable squashed/rebased changesets to SVN as a service user.
I would like a concrete example with the following scenario.
Last mercurial hash at step 2 - A
Current mercurial hash after pushes step 3 - B
Hash of last commit after pull from upgraded SVN - C
Hash of step 2 commit after full SVN history pull - D
I am not very good at ASCII art, feel free to add one for bonus points.
We did a CVS -> Mercurial migration last week at work. Like in your case, some people continued to use the CVS for a time.
In order to sync the the two repositories when the CVS server was finally shutdown, I did the following :
Convert the CVS to mercurial via cvs2hg
Export each new revision with hg export
Import the patch files with hg patch
There was only a dozen revisions, so this was no big deal... If you have many more revisions, you could maybe take a look at the transplant extension.
Hope this helps.
Related
I want to checkpoint/commit stages (locally) using mercurial, knowing well that these changes would break the build if I pushed them to the remote repository. What I would like to do is fold/collapse/accumulate these changesets into a single changeset that I can push. I do not want the the remote repository to have these intermediate checkpoints in its history. I would like all recorded versions on the remote repository to at least build properly.
Is there any simple way to do this, perhaps an extension. I would have assume that this would be a selling point of a DVCS.
Histedit extension (fold command)
or
MQ extension (qimport + qfold + qfinish cycle) - "Combining entire patches" chapter in chapter Managing change with Mercurial Queues of "Mercurial: The Definitive Guide"
I am making say 4 local commits in HgSVN, then I updated my local code to an earlier revision, I added changes to it, did local commits, merged with server code and when tried to push, I was not allowed because of the 4 local commits not merged.
How to delete/remove these 4 local commits from HgSVN history and push the code ?
What should be done in this scenario ?
using HgCommit for saving code to the local machine and
HgWorkbench for pushing the local changes to the server
Your main big problem: you prefer do nor read docs and use tools blindly. Otherwise you have to know one of the biggest limitation of HgSubversion: it is not possible to push back to Subversion mergesets from Mercurial
"...Mercurial merges cannot be pushed to Subversion"
Also, HgSubversion page on Mercurial wiki clearly states:
The important point to note is that hgsubversion cannot push merge changesets to a svn repository. This means you should not try to merge this new head -- if you do so, hg push to svn will fail. Instead, you should rebase the changesets that you want to push to the Subversion repository (see Rebasing changes below)
Summarised Question:
Are github-hosted sub repositories within a mercurial/kiln repository possible, and if so are they automatically updated/cloned when the parent mercurial repository is operated on by a hg clone or hg commit command?
Detailed Question:
Following on from my question that was answered so excellently here , some of my third party code is in folders I downloaded a while ago from opensource efforts on github. Since at that stage I was not using version control, those folders where just standard folders that now been incorporated as sub repositories in mercurial.
This is obviously not ideal, as for one thing, new versions of the libraries may have bug fixes, or new features I wish to use in the future. I also may need to locally customise some of the libraries.
I can see from reading this link that it possible to have mercurial "know" about those git server urls (and revisions), so I can then have mercurial clone the github hosted libraries direct from their parent repos.
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
What is also not clear is, if I were to do this, and it transpired that code might need to be customized from within that github-cloned repository, would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
Yes, clone of a Mercurial repository that contain subrepositories will trigger a clone of the subrepos too. It really happens on update. Mercurial notices the .hgsub file and issues the needed hg clone and git clone commands for you. It uses the information in .hgsubstate to know exactly what revision to checkout.
The subrepositories can be hosted anywhere. For a Git subrepository declared like
foo = [git]https://github.com/user/repo.git
Mercurial will simply issue the corresponding clone command:
git clone https://github.com/user/repo.git foo
It's then your reponsibility to later go into the foo repo and use Git to fetch new commits as necessary. After you fetch/pull new commits, you can make a top-level commit to record the new state of the subrepo in the .hgsubstate file. Use hg summary to see if a subrepo is dirty in this sense.
[...] would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
When you edit files and make a top-level hg commit, Mercurial will make sure to commit the subrepo first (if you use hg commit -S or if ui.commitsubrepos=True). If you make a top-level push, then Mercurial will always push the subrepos first so that you always have a consistent set of changes on your server.
I'm a VERY happy user of bitbucket and mercurial after years of putting up with subversion (and CVS, SourceSafe and others; anybody remember SCCS?). I've considerable project history now in my local hg repo, pushed daily to bitbucket and thence to my home machines.
Problem is, my company wants me to maintain a copy of this history in subversion. And I've hit a stone wall trying to set this up. I've installed hgsubversion, I think correctly. And I've used svnadmin to create an empty svn repository ready to hold the hg history.
But now what? The instructions say to start by pulling a clone (of nose? what's that? I assume this means checkout a copy of the new empty svn directory. OK did that.
But now what? I assume the next step is to push my real local hg clone to the empty svn repo I just checked out. But nothing I've tried will do this. Pull fails as follows, reporting "unrelated repository" (as I recall I gate it the URL of my master local hg repo to get around the "Needs a URL" popup on everything else I've tried.
found new changeset 139d02f4b233
examining 4e97a23b6815:342df9e52cec
abort: repository is unrelated
[command returned code 255 Mon Apr 25 11:29:33 2011]
The result of all this fumbling around is a directory with .hg, .svn and .hgignore entries and nothing else.
So, I feel I'm missing something basic that hundreds of others must have tried by now. Can someone please help me get started? Thanks!
PS: Currently the intent is to maintain SVN permanently as the team repo and push changes there from Hg periodically which would remain the main client for me indefinitely. In case this matters...
You can use the convert extension:
hg convert --dest-type svn mercurialrepo svnrepo
And hgsubversion allows you keep both of them in sync ( bidirectional)
Answered here at SO already:
Converting from Mercurial to Subversion
Migrating from Mercurial to Subversion
Perhaps look at the answers to this question.
Hgsubversion is for working with a repository cloned from SVN using Hg, not the other way around.
I've got a gigantic CVS repository that I'd like to convert to a few hg repos. This question is similar, but I'm using hg convert and I've got more than one directory in cvs that should go in a given hg repo. Here's an example:
/sw
.../dir1
.../dir2
.../dir3
.../dir4
.../dir5
I want dir1, dir2, and dir4 in my hg repo, but dir3 can rot with dir5 in a separate one that nobody will ever use.
I've been converting the whole thing with hg convert --branchsort sw where sw is a sandbox checkout containing only the directories I care about. That nets me a 1.7GB hg repo with all 4 directories. The CVS repo is 2.3GB, but a sandbox is only 159MB. The hg repo has history going back to 1997, which is awesome, but some of the stuff in there is from products that have been discontinued. They don't need to be in a regular developer sandbox.
So, is there a way to cherry pick CVS directories to go into my new hg repository?
You should follow my advice on that question to which you linked. Convert everything together and then use hg -> hg converts to pick the parts you want in each repo using a filemap. Any revisions that would be empty (have only files that you're excluding in that conversation) will be omitted.
Also hg to hg converts are much faster, so you can do the slow CVS convert only once and then do the hg to hg parts again and again until you're happy with the results.
Do you have access to the CVS repository storage?
If yes, then you should be able make a complete copy of the repository, remove any files/directories that you don't want to convert, and then run hg convert with a working directory checked out from this local repository.
I say should because I haven't tried it, but since CVS stores revision history on a per-file basis, there's no reason I can think of that it shouldn't. It would not work with a SCM like Subversion, which stores multiple changes in a single revision.