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 am using Mercurial(TortoiseHG) as version-control system for our source code. I am unable to remove a file from the repository, from the command-line. I see several people on web, giving solutions like:
1. hg rm
2. hg remove
These commands do the operation of removal from the directory. However, when I pull the repository at a seperate place, the above file(supposed to be deleted) still shows up. I tried pusing the repo after performing the above commands as well, with:
hg push
But the files are not really removed from the repository. Do I need to configure anything extra for this removal operation?
I generally have the habit of committing at the leaf-level, and thus wasn't committing the root repo folder all the while. Sorry for the miscommunication.
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.
There can be:
1) just clone from remote repo as needed (each new one can take 20 minutes and 500MB)
2) clone 2 local ones from remote repo, both 500MB, total 1GB, so always have 2 local repo to work with
3) clone 1 local one from remote repo, called it 'master', and then don't touch this master, but clone other local ones from this master as needed
I started off using (1), but when there is a quick bug fix, I need to do a clone and it is 20 minutes, so then method (2) is better, because there are 2 independent local repos all the time.
But then sometimes a repo becomes "weird" because there are merges that do damages and when it is fixed on the remote repo, any local repo's merge that shows up in hg outgoing will cause damage later when we push again, so we just remove that local repo and clone from remote again to start "fresh", taking 20 minutes again. (Actually, we can use local repo 2 first, rename local repo 1 as repo_old, and then before sleep or before going home, do a clone again)
Is (3) the best option? Because on a Mac, the master takes 500MB and 20 minutes, but the other local clones are super fast and takes much less than 500MB because it uses hard link on a Mac (how to find out how much disk space without the hard linked content?). And if using (3), how do we do commits and push? Suppose we clone from remote repo to local as "master", and then clone local ones as "clone01", "clone02", 03, etc, then do we work inside of clone01, and then when an urgent fix is needed, we go to master, do an hg pull, and hg update, and go to clone02 and also do hg pull and hg update, and fix it on clone02, test it, and hg commit, hg push to the master, and then go to master, and do an hg push there? And then when clone01's project is done, again go to master, pull, update, go to clone01, pull, update, merge, test, commit, push, go to master, push to remote repo? That's a lot of steps!
Maybe a fourth option might work better in your case: Mercurial Queues that are kept in a local Mercurial repository.
Using MQ you can:
Clone the master repository locally.
Work on your code and keep your changes isolated in patches.
When new updates from upstream are available, remove your batches, apply the updates, and then re-apply your patches on top of the new update.
Once you're happy with your work, fold it into your local repository and push it upstream.
You don't have to keep the patches in a local repository, but it's a nice bonus option that is worth considering.
Chapter 12 from Mercurial: The Definitive guide explains the process in fairly good detail.
I don't know that your understanding of the space considerations are correct. When cloning a local repository Mercurial will use hardlinks for the .hg directory, the actual repository, which takes up no additional space. The working directory takes up space (though hopefully not 500GB!) but the .hg directory only looks like it does depending on the tools you use to check.
If you do a clone -U you create a clone without a working directory and it should take up almost no additional space and be created almost instantly.
I always keep a clone -U of the central repo in an unmodified state and then create clones off of that as needed. I push directly from those clones back to the remote repository.
Mercurial Queues look really powerful, but I've never given myself the time
to read all that documentation, just to be able to put my current work aside to
work an a small bug.
I use the attic extension.
It'll be like this:
...working happily, but then there is a quick bug fix...
$hg shelve work
...quickly fix the bug...
$hg ci
$hg unshelve
...continue with work
Sometimes I get an idea, but no time to really play with it. To prevent me from forgetting it.
...working happily, idea drops in...
$hg shelve work
...start a unittest for the idea or some other unfinished piece of code, enough to sketch the idea
$hg shelve idea
$hg unshelve work
...continue with work
$hg ls
idea
*C work
I've just recently moved a lot of my Views and Controllers into more appropriate locations and am now wanting to pull down recent changes from our central repo.
I've done a hg pull which worked fine and asked me to do a hg update to bring the changes down locally. This in turn informed me that I needed to do a hg merge however when I try this, I get a message stating that
abort: outstanding uncommitted changes
When I check this using hg status I see in the list all of the files that I've moved (so they're now deleted from their old location).
How do I tell Mercurial that I've removed these files? Do I have to go through each one of them and manually do a remove? Is this something that's possible using only the command line rather than doing it with a GUI tool?
From the command line to automatically hg rm the files you've removed you'd:
hg addremove
It's likely your GUI (you didn't say which you use) exposes that functionality too.
However, that's not what's causing your message. You have some already made local changes that mercurial does know about (unlike the removed files which it doesn't know about until you tell it), and you need a hg commit before you can merge.