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!
Related
We have a project that lives in a mercurial repository.
Our customer would like to take ownership of the code base by doing the following:
Set up a mercurial repository on a server belonging to the customer.
Import the existing code into the new mercurial repository.
What is the best way to achieve step 2?
Is it a simple matter of doing the following:
Clone the existing mercurial repository:
hg clone <existing mercurial repo URL>
Push the cloned repository into the new one:
hg push <new mercurial repo URL>
Am I missing any steps? What about the hgrc file? Does it have to be modified in any way prior to pushing the project into a new repository?
Yes, you can do what you state, however it is worth noting that if you do a simple hg clone of your main repository, then a link will exist between the two, which may not be what you want. You can remove this link by editing the .hg/hgrc file and removing the default = ... item in the [paths] section.
I find that a better way is to do it without cloning. This way you don't have the link between repositories, which as this is going to a customer may be what you want.
The basic method is to set up a new repository with no changesets, and then bring in all of the changesets in one of three ways:
Push the changes from your repository to the new repository.
Pull the changes from into the new repository from the old.
If you don't have access to the new repository, create a bundle that can be provided to the customer - this can then be unbundled or pulled into the empty repo.
Pushing and Pulling is done as you normally would, but specifying the repository location:
// create the empty repository
hg init .
// pull in everything from the old repo
hg pull /projects/myOriginalRepo
or to push...
// create the empty repository
hg init /projects/myNewRepo
cd /projects/myOriginalRepo
hg push /projects/myNewRepo
Creating a bundle is perhaps a nicer way, as you can write the bundle onto a DVD and give it to your customer wrapped in a bow with a nice greeting card:
cd /projects/myOriginalRepo
hg bundle --all ../repo.bundle
Everything gets written out to a single file, which can then be extracted with hg unbundle repo.bundle or hg pull repo.bundle, into a repository with no existing changesets.
Regarding the hgrc file, as already mentioned in another answer it is not a controlled file, and so won't be copied. However, any contents are likely things like hooks to perform auto-building, or validating changesets before they are applied. This is logic which would probably only make sense to your own organisation, and I would suggest you wouldn't want this to be imposed on your customer - they are, after all, taking ownership of your code-base, and may have their own systems in place for things like this.
In the simple case - it's all.
But if you have modified .hg/hgrc file then you need to move it to the remote server manually and (if necessary) modify it correspondingly to a new environment.
Ie: you could have hooks set up in the original repository.
As of clients - just change a path to a repository in a default section (or any other section if you have several specified)
To move the master repository, you need to (a) create the new master repo and (b) tell the existing clients about it.
Create the new master repo any way you want: cloning or init+pushing, it makes little difference. Be sure to move any contents of the old repo that are not under version control, including .hgrc and any unversioned or ignored files that are not discardable. If you cloned, edit the new master's .hgrc and remove the default path, so that it doesn't try to talk to the old master repo any more.
Existing clones of the old master repo still push/pull from the old master. Everyone must edit their .hgrc, updating default (and/or default-push) so that it points to the new location. (They may also need to update authentication credentials, of course).
Only then is the migration complete. Remove (or move/hide) the original repo so that if someone forgot to update their repo path, they'll get an error on push/pull instead of pouring data down a memory hole.
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 a project where I'm using Bitbucket as my HG server, but I've recently discovered that as a lone developer I can use Fogbugz/Kiln for free. I want to move my files into Kiln but I don't want to lose my history. I'm sure there's a dead-stupid easy way to do it, but I just don't know. How do I do this?
Thanks!
Create the new project repo and do the following with your current copy of the original repo: hg push new-repo-path.
Then you use the new path in the future. You can delete the bitbucket repo.
With Mercurial, all history is in every copy of the repository, including your local copies.
Since you are already using Mercurial. I was just curious, shouldn't cloning your repository on Fogbugz/Kiln be sufficient.
hg clone "BitBucket Repo ..."
Of course, this won't copy your per-repository hgrc file. You will need to do that separately.
Another approach is to use bundle.
hg bundle --all bitbucket.bundle
hg clone bitbucket.bundle my_repo
Third approach is to push or pull from bitbucket repo to fogbugz repo.
Setting defaults
See: https://www.mercurial-scm.org/wiki/TipsAndTricks.
Reproducing it here:
It is possible to store a default push URL that will be used when you type just 'hg push'. Edit hgrc and add something like:
[paths]
default-push = ssh://hg#example.com/path
The other answers have already explained that right after creating a new empty repository, you can push your changes into it with hg push http://example.com/hg/newrepo. (Note that once you have pushed some changes into it, it will only accept changes from related repositories in the future.)
What you also seem to be wondering about also is how to then configure your local repository to push to that location by default, without needing to specify the URL every time. You can do that by editing the default location in the .hg\hgrc file of your repository. It is a text file that you can open with notepad or any other text editor.
I’m just getting started with Mercurial, and I’ve read Joel Spolsky’s Hg Init tutorial, which I liked.
I’m wondering: let’s say I have a private repository and I work on it for about a month. Then I decide I want to centralize it or make it public, like on bitbucket.org. I want to retain all the history.
The intuitive thing would be to use hg clone, but according to the docs:
The location of the source is added to
the new repository's .hg/hgrc file, as
the default to be used for future
pulls.
I don’t think this is what I’d want, since the source is my local, private repository, and the destination is the public server. I don’t want the public server trying to pull from my private repository in the future thinking it’s the central one. I hope this makes sense.
Do I have to tweak the .hg/hgrc file on the server manually? Am I approaching this correctly?
BitBucket's help says it's as easy as making an empty repo on BitBucket, then pushing to it:
... create a new empty repository via the "Create repository" page. We will assume that this repository is named blonk and is to be found on http://bitbucket.org/jespern/blonk.
Now, just push to it:
$ cd ~/Work/blonk # our existing hg repository
$ hg push http://bitbucket.org/jespern/blonk
...
Done!
You can edit .hg/hgrc in your repository to include the default path to Bitbucket:
$ cat .hg/hgrc
[paths]
default = http://bitbucket.org/jespern/blonk
Now you can simply enter hg push and hg pull without having to specify the full URL.
Doing this operation using 'hg push', as described, is probably the best way to do this, overall.
However in other circumstances it might be convenient, or reassuring, to note that all of the Hg state is contained within the .hg directory, and so simply moving this directory is enough to move the repository.
For example, if you have ssh access to a machine at example.com, you can tar (or zip) up your .hg directory in the 'private' repository, unpack it in, say, ~/repo/foo on the remote machine (thus creating a directory ~/repo/foo/.hg there), and then simply clone this:
$ hg clone ssh://example.com/repo/foo
This does have a slight back-door feel to it, I agree. However, there's nothing really under-the-hood happening here, and no editing of configuration files is necessary. When I do this, I find it less confusing than the 'proper' way.
If I have a rather large Mercurial project locally, and wish to experiment, can I safely just make a local copy of everything and work there?
For instance, let's say I do this:
Clone the repository from a central server to a local directory
Make some changes, commit them locally, do not push
Make a copy of the directory locally
Make some changes in both copies locally, commit, do not push
Push original copy
Push second copy
Will this be safe? Or is there some unique ID's being generated when I clone?
One project is rather large, and the server has a rather slow connection, or so it seems, so it takes ages to do a full clone from the central server.
Yup, that's perfectly safe.
The only differences I can think of between cloning a repository locally, hg clone a/ b/, and copying the repository, cp -r a/ b/, are:
Cloning will use hard links, if possible, so less disk space will be used
Repository-specific configuration (eg, a/.hg/hgrc) will not be coppied by hg clone
If you clone, the default push/pull path of b/ will be set to a/
So, yea — no problem with simply copying the repo.