A former colleague somehow made a large commit in a mercurial repo and now its very large. I haven't found the commit but bitbucket reports that the repo is > 1gb which it shouldn't be.
Is there any way to find which revision added alle the large files and delete it from history?
Related
I have a shell repository OriginalWithSubrepo with a subrepository Sub containing a bunch of actual files.
When I clone OriginalWithSubrepo like this
hg clone --pull --noupdate "C:\TestRepo\OriginalWithSubrepo" "C:\TestRepo\OriginalWithSubrepo-clone"
The clone thus created contains just a few mercurial housekeeping files, there is no actual data from the original Sub\.hg directory. I don't know what those files mean but apparently they are enough to recreate the repo because when I update the working directory in clone, the whole thing gets filled out with all the files, including inside the Sub\.hg directory. However, if I clone, then rename the original, and then attempt to update the clone, it doesn't work saying the OriginalWithSubrepo is not found, which means it's all based on links to the original.
This problem doesn't arise when I run clone with update, or when I clone a repository without subrepos.
It behaves the same when I clone to a network share, which is where I really want it to work.
So how do I make a fully independent clone of a repo with subrepos (w/o a simultaneous update)?
Windows XP, hg version 3.4.1
When you add the first subrepo to the parent repo, .hgsub is added to the parent repo. The subrepo only becomes a subrepo from the changeset that commits .hgsub.
When you do hg clone --noupdate --pull parent parent-clone, parent-clone is not at any changeset yet, and so not yet at a changeset at which the subrepo has been created
So how do I make a fully independent clone of a repo with subrepos (w/o a simultaneous update)?
I don't think you can do this as such.
But this may achieve what you're trying to do (I'm reading between the lines here, but I'm guessing to have the repo on the share, but without any files visible):
Create repos on your network share for your parent and sub \\fileserver\repos\OriginalWithSub\ and \\fileserver\repos\Sub\
Modify your local OriginalWithSub .hgsub set the remote path to be \\fileserver\repos\Sub\ and commit.
push your local repositories to their respective network share equivalents.
Both repositories now exist on the network share, without any files visible apart from inside .hg, and you can clone \\fileserver\repos\OriginalWithSub\ (with update) from another computer and get the full history of both OriginalWithSub and Sub.
We have a large, old repository with largefiles. I want to replicate the repository to a backup server using a cron script that runs hg pull. However, this command doesn't retrieve the largefiles.
I currently have 2GB of history replicated, but I'm missing 6GB of largefiles. How can I get Hg to pull down those important files?
By default, only largefiles for the revision you update to will be downloaded.
'hg help largefiles' says:
When you pull a changeset that affects largefiles from a remote repository,
the largefiles for the changeset will by default not be pulled down. However,
when you update to such a revision, any largefiles needed by that revision are
downloaded and cached (if they have never been downloaded before). One way to
pull largefiles when pulling is thus to use --update, which will update your
working copy to the latest pulled revision (and thereby downloading any new
largefiles).
If you want to pull largefiles you don't need for update yet, then you can use
pull with the "--lfrev" option or the "hg lfpull" command.
You should be able to use 'hg lfpull --rev "all()"' for this purpose.
I have a mercurial repository my_project, hosted at bitbucket. Today I made a number of changes and commited them to my local repository, but didn't push them out yet.
I then majorly stuffed up and fatfingered rm -rf my_project (!!!!!).
Is there some way I can retrieve the changes that I committed today, given that I hadn't pushed them out yet? I know a day's worth of commits doesn't sound like much, but it was!
All the other clones I have of this project are only up-to-date to the most recent push (which didn't include today's changes).
cheers.
mercurial cannot save you. The data from mercurial is stored in a hidden directory in the base of your project folder. In your case, probably at my_project/.hg. Your recursive delete would have trashed this folder as well.
So maybe a file recovery tool?
No. The changes are only stored in the local repository directory (the .hg directory therein) until you've pushed. They're never put anywhere else (not even /tmp).
There is a possibility that you'll be able to recover the deleted files from the disk, though; search around for instructions and tools for doing that.
I'm afraid the commit is deleted together with the working copy and file recovery tools are your only option to recover the missing .hg folder. I see you could recover the code from the install — great!
If you're afraid of this happening again, then you could install a crude hook like
[hooks]
post-commit = R=~/backup-repos/$(basename "$PWD");
(hg init "$R"; hg push -f "$R") > /dev/null 2>&1 || true
That will forcibly push a copy of all your commits to a suitable repo under ~/backup-repos. The -f flag ensures that you will push a backup even if you play with extensions like rebase or mq that modify history. It will also allow pushing changesets from unrelated repos into the same backup repo — imagine two different repos named foo. So the backup repositories will end up with a gigantic pile of changesets after a while and you might want to delete them once in a while.
I tested this briefly and for everyday work I don't think you'll notice the overhead of the extra copy and you might thank yourself later :-)
I'm starting with Mercurial. I'm reading the mercurial book but still have a question.
I've started my project month ago, and i have a lot of files and directories in it. Now, i want to use Mercurial and made myself an account in bitbucket. Now, i want to set this project up in Bitbucket. How can i add all those files to the bitbucket repo?
This is what i was thinking i could do:
I could try to (1) clone the empty repo (from bitbucket) (1) copy all files into that directory, (3) issue an "hg add" and after that (4) commiting.
Maybe you have a better way to do this.
Thanks!
(1)
hg clone https://ME#bitbucket.org/ME/myproject
(2)
cp existing-project/* myproject/
cd myproject
(3)
hg add
(4)
hg commit -u ME
(5)
hg push (i think i have to do this to make the changes visible)
You can simply hg init, hg add, and hg commit in the original project folder, then edit ~/project/.hg/hgrc to add a default-push location of your bitbucket repo (you can clone it to a temporary folder to get the hgrc created for you which you can copy into your project, even, without needing to RTFM for the right syntax.)
Because of the distributed nature of mercurial, this hgrc entry is the only thing relating your local repo to bitbucket at all; you can even hg push https://ME#bitbucket.org/ME/myproject without making the link explicit anywhere. Each copy of a repository is completely self-sufficient.
Wooble's answer is ok, but it's missing something, so I'm supplementing here.
When you first create an empty repository (by hg init or creating on bitbucket), it has no identity. However, as soon as it has any changesets, it has an identity and you can only push/pull between it and repositories that share that identity.
If you had 2 repositories A and B for separate projects, you wouldn't be able push/pull between them. Once you create a new repository on bitbucket you can push changesets from either A or B to that repo once. If you push changes from B that first time, the bitbucket repository is now related to B. You can't then push changesets from A into it, or pull changesets into A from it.
So when Wooble says,
...this hgrc entry is the only thing relating your local repo to bitbucket at all;
That is correct while it is still empty as it is not related to any repositories until it has changesets. And you still need that address to be able to push/pull between your local repo and the bitbucket repo, but once you've pushed changesets to it it also has that identity that relates it to your local repo.
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.