In a previous commit we had say folder EXAMPLE1 in the Mercurial repo and had to be deleted due to project configuration issues.
The project has been reorganized and a folder with the same name (EXAMPLE1) needs to be added again.
Mercurial is currently not allowing commit for that specific folder. No errors are shown. However, when commit is attempted, it shows as if nothing has been changed inside the folder.
Would appreciate it if you could please tell me how can the folder labeled as EXAMPLE1 can be added back to the mercurial repo.
Related
In my repository somebody committed files that should be unknown (or ignored, according the .hgignore file).
How can I tell to Mercurial to no longer track those files but leave the files as unknown (or ignored) on remote working copies? (With remote working copies I mean working copies of the other users of the repository.)
More details: Specifically those files are .classpath and .project generated by Eclipse IDE when the project was imported as Maven/Gradle project. They have been added to the repository and committed. I want to do not track changes of that files but I don't want to ask everybody to re-import the project into Eclipse again. Renaming .classpath and .project to .classpath.template and .project.template does not resolve my issue.
That is tricky, as the file will be stored as deleted in the changelog when you tell hg to forget it - and on update it will be deleted in the working dirs of everyone who pulls and updates to a rev later than the one where those files have been removed from tracking.
If you can get by with everyone using hg revert -rTRACKED FILENAME where TRACKED is the changeset where the files are (still) tracked, it is not really nice but probably the easiest solution.
You might want to add all files you do not want to be ever tracked to add to your .hgignore so that these won't be added by hg addremove accidentially.
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.
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.
I have a project, which is in the Mercurial repository. In the root folder there is a .hgignore file, which states, that the "Bin" folder should be ignored (and also some other files and folders).
Now I want to clone this repository but in a way, that ALL folders and files should be cloned, also the original ignored ones. If I just clone the repository, than I get only the files, which are included in the repository thus my bin folder is missing.
How can I get cloned repository with all files in it? I want to merge these two repositories together in a while...
PS - I am working on a legacy application which has a lot of external dll-s in the bin folder of the application. I know I should put them to a seperate folder, but that's another story.
Just copy it.
Copy the whole tree from point a to point b, and the new copy will function perfectly as a repository. The only thing that would be different from a clone is the lack of hardlinks and that the default pull/push path will be set-up to be the same as the original, rather than pointing to the original. That's easy to change by editing .hg/hgrc if you want to.
An ignored file is not in your repository, so it will not be cloned. You should copy these files by hand after you have cloned the repository.
When you copy those files, I think it won't be a problem if you overwrite other files that are in your repository (they're essentially the same files after all), so as long as you don't copy the .hg folder in the root of your checkout, you'll probably be fine.
Newbie alert!
OK, I have a working central Mercurial repository that I've been working with for several weeks.
Everything has been great until I hit a really bizarre problem: my central server doesn't seem to be synced to itself? I only have one file that seems to be out-of-sync right now, but I really need to know how this happened to prevent it from happening in the future.
Scenario:
1) created Mercurial repository on server using an existing project directory. The directory contained the file 'mypage.aspx'.
2) On my workstation, I cloned the central repository
3) I made an edit to mypage.aspx
4) hg commit, then hg push from my workstation to the central server
5) now if I look at mypage.aspx on the server's repository using TortoiseHg's repository explorer, I see the change history for mypage.aspx -- an initial check-in and one edit. However, when I select 'Diff to local', it shows the current version on the server's disk is the original version, not the edited version!
I have not experimented with branching at all yet, so I'm sure I'm not getting a branch problem.
'hg status' on the server or client returns no pending changes.
If I create a clone of the server's repository to a new location, I see the same change history as I would expect, but the file on disk doesn't contain my edit.
So, to recap:
Central repository = original file, but shows change in revision history (bad)
Local repository 'A' = updated file, shows change in revision history (good)
Local repository 'B' = original file, but shows change in revision history (bad)
Help please!
Thanks,
David
Sounds like you're looking at the working copy on the central repo. Just like your local repo, there is a working copy. Running hg update (or "Update to branch tip" in TortoiseHg) should sync the central repo's working copy to the latest.
This is normal, as the repository on the server has two components: the actual repository of changesets (in the .hg subdirectory), and a working copy. When you push changes from the local repository on your workstation to the server repository, it updates the repository files on the server (in the .hg subdir), but it does not change the working copy files (outside the .hg subdir): this would require an explicit update operation on the server to change the working copy.
If the server repository is only being used as a repository, and you do all your actual work in clones, then you're probably better off using a "bare repository" on the server (just delete the working copy files and just keep only .hg subdirectory itself).