How to kill mercurial repository? Can't find the command to accomplish the task.
I'm not sure what you mean by "kill", but you can remove a repository by deleting the .hg directory in your clone. Or just delete your entire clone directory.
Be sure this is really what you want to do, though. There's no undo.
Related
I want to understand how mercurial works on the server side. So I do some local experiment and can't understand what is going wrong.
I make two directories /server and /client then go to /server, make new directory /server/repository, go to /repository and call hg init.By this I have an hg repository.
Then I go to /client and call hg clone file://path_to_server/server/repository. It clones empty repository to the /client folder. Then I create new file and put it under hg control doing hg add file, commit it and push. I expect a file in the /server/repository/ but it's still empty.Maybe my expectations so naive and behaviour I expect is incorect. It also might be really doubtful thing - moving files locally by pushing from /client to /server without any command in /server/repo/ folder. In this case I hope anybody explain why that doesn't word this way and what should I do.
You need to hg update on the server repository.
The working directory (which is the set of files you see in the filesystem) is not automatically updated when new changesets arrive either from pulling or pushing changes from another repo.
Good Luck!
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 have been happily using HgSubversion for awhile and today I forgot to add the --svn to the rebase command.
Now i get the dreaded unknown revision ''
Is there a way to recover from this?
You should be able to do "hg svn rebuildmeta" and then do "hg pull" and have it repair things.
Note: this is untested, so I'd work on a duplicate of the local repo in case it screws things up. My memory of the code suggests this will work.
I'd try using the transplant extension to fix this:
Re-clone the SVN repository to a new local repository.
Examine the history of the original repository and note which changes need moving
Transplant the changes from the old repository to the new repository
For example - fixing an hgsubversion repo called project:
> hg clone svn+http://svnrepo/project project-tmp
Then examine the log of your original project folder and do the following from the project-tmp folder:
> hg transplant -s ../project 1234
Where 1234 is the revision that you want to move over. Repeat this until all your revisions are copied.
When you're done you should be able to start using the new folder in place of the old folder by re-pulling from SVN, rebasing your changes and push them back (don't forget --svn)
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 an mercurial repositry a bitbucket.org and a clone on my wokstation. The clone has some uncommited (unfished) work in it. I have to copy these clone to my laptop because I will be on a trip for one or two weeks and want to do some work.
Is there a simple and save way to copy the repository with its uncommited changes to another device? I knew I could clone the repo from the workstation to my laptop but this won't copy uncommited work.
Simply copy the entire repository's folder.
Just commit that work. That work needs to be finished to be committed is left-over CVS/SVN thinking. Commit it, and then update to its parent and work on whatever else you want to work on. When eventually the work is done you're pushing a changegroup not individual changesets, so no one will have the uncompiling stage at the end of those interstitial changesets on them.
Avoiding committing work in Mercurial (using shelve, attic, copying repos, etc.) is the only way to lose work -- avoid it.
I prefer my first answer (commit it) but if you positively can't bring yourself to commit unfinished work then you should be using Mercurial Queues with a patch queue that lives in its own repository. This is easily done with:
hg qinit --create-repo
Then you import your uncomitted changes as a patch using:
hg qnew --force name-for-this-work
then you can:
hg qcommit -m "work in progress"
Then you can qclone that repo and get both the work in progress and the base repository on which it's overlayed. More details are available in the Mercurial book's chapter on queues.
Really, though, there's just never a good reason to have uncommitted work for more than an hour or two.