I am using Tortoise HG two handle source control for a couple of projects on my local machine. I am pushing to a local directory elsewhere on the HD, just as a way to handle revision history.
My directories are set up like so:
Projects are located here: like MyDocuments\Project1.
I push commits to here:
C:\Repository\Project1
C:\Repository\Project2
For one of these projects, this works. For the other, when I try and push, I get an error that it cannot find the directory. Security settings (Windows 7) are the same for both directories.
MyDocuments\Project2 was under this source control at one time, and then something got messed up. So, I deleted the .hg file and hg directory and started over, creating a new repository there and adding all the files for the initial commit. But the initial commit will not push. It says:
repository C:\Repository\Project2 not found
I'm at a loss. I've deleted the HG files and directory three times and started over, but I cannot push. I've tried pushing to a different directory - no luck. I am guessing something is glitched from trying to start over.
You shouldn't delete the .hg folder as that is what makes it a Mercurial repository.
I'd say that the solution would be to re-clone the MyDocuments\Project2 repository to C:\Repository\Project2 and start again from there.
In future, if you get to the position where you feel that you need to delete the .hg folder, don't. Come back here and see if we can do anything to help resolve the problem.
Related
I would like to have a central repository in a directory on my local computer without setting up a server.
Context: I am working with my boss on a local server inside our LAN. We both are using a vnc connection onto the server, and are doing our work there for simplicity reasons. I would like to set it up so that I can have a copy of my scripts for development, and then when I get to a release, I will push it to a different directory that my boss can then run them from (or even better pull from to his own set and run from there).
I read that you can create a hg server by running 'hg serve', but I do not want to open it up to the LAN, because I don't want it to be accessible.
I tried running 'hg push /home/source' and it gave me an error.
I then ran 'hg init' while in that directory and tried again. It looked like it worked, and then didn't show any files in the directory. I ran status and it showed nothing, and then ran log and it showed the commits.
... without setting up a server
One way I've used to share a "central" Mercurial repository without having to deal with any "server" issues is to have the "central" repository in a folder on Dropbox.
For example, suppose:
your repository is named "repo" and that your "private" copy is in ~/repo
your Dropbox directory on your computer is ~/Dropbox/
Then:
cd ~/Dropbox
hg clone ~/repo
Now suppose you make some changes in ~/repo. You can then "push" them from ~/repo to ~/Dropbox/repo, or (more easily, as explained below) "pull" them into ~/Dropbox/repo when you're ready.
To make updating the "central" repository convenient, you might like to create a script such as:
#!/bin/bash
cd ~/Dropbox/repo
hg tip
hg pull -u
hg tip
Notice that in the script, there is no need to specify the source from which to pull; the hgrc file that's created when you created the clone keeps track of that. (Thank you, hg.)
If your colleague has direct access to a folder on your computer, then you could still adopt the strategy described above, without using Dropbox.
Needless to say, there are many variations.
Needless to say also, if more than one person attempts to commit changes to the shared folder, chaos can easily ensue.
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!
Just the other day I was having some problems with my XCode project so I deleted all of the files in my project directory, downloaded my latest commit from BitBucket, and copied all the files from that directory into my empty project directory. Yes I know this was pretty dumb, but now when I try to make a new commit I get: .hg not found. Is it possible to fix this or have I permanently screwed over my repo?
The whole mercurial repository usually remains in your working folder, right under the sub-folder .hg. I say usually, because by deleting your working folder, you also deleted your repo, so yes, it cannot be found anymore. Simply downloading your latest state does not bring it back.
Don't worry, since you had the whole repo in Bitbucket, you only need to reclone. Make a manual backup of your current changes before doing so, if you don't want to loose them.
When I create repository and push on server and when we clone the repository in local system the files are come with red signal means they are changed.
When we compare both repository I found that the content of files in .hg folder is changed.
Can anyone pls tell me how to remove this problem!
Edit:
When we change the .hg folder the red icon becomes green!!!!
If you take 1 modified (changed) file, watch the diff closely, and only see the difference is in new lines only, this is the classical newlines mess.
(happens to most people when working crossplatform)
There is a ready to use Mercurial Extension, taking care of this is problem.
It's called eol.
Learn how to use it and the problem from here:
https://www.mercurial-scm.org/wiki/EolExtension
how do you push localy created repository to server? If there is no repo with same name(on server), you could not be able to create remote repo by push, you have to clone it to the server. Or, if there already is repository with same name, and you push some new localy created, there definitely will be something more in .hg on the server then on the local. Check if there isn't repo with same name on the server already. HTH
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 :-)