I need to remove a project entirely from Mercurial source control. I am the only programmer who has ever worked on it.
Just delete the '.hg' directory. Everything related to history and source control is in there.
Related
I have been struggling with following problem regarding source codes versioning with Mercurial usage. On one hand I have got source codes in local working directory and those source codes are under Mercurial control. On the other hand I have a copy of those source codes in automatically generated workspace in my IDE and those source codes are not under Mercurial control. That is the problem. Because I will do modifications in the source codes via my IDE. So I will modify the source codes which are not under Mercurial control. I need to have some synchronization mechanism ensuring that changes done in my source codes via my IDE will reflect into the working directory.
I have got an idea that I can achieve this synchronization mechanism by extending the hg commit command somehow in such a manner that it first copies the source codes from workspace into the working directory and then the commit actually executes.
Can anybody tell me whether the idea described above is feasible? Thanks for any suggestions.
Can anybody tell me whether the idea described above is feasible?
In short - no. Just because your IDE-space (now) doesn't linked to Mercurial at all
Good and correct and practical way will be:
work in Working Directory, which have to be also your IDE-space, with ignoring all unwanted artefacts of you IDE
don't duplicate amount of authoritative sources
I'm quite frequently finding myself needing to rename a file that's deep in a sub directory somewhere and it's a pain having to expand the folders using the sidebar manually to be able to right click and rename.
Does anyone know of a quicker way of doing this? maybe some kind of extension that expands the folder sidebar to the current file you're working with?
Thanks.
Going to plug one of my plugins here, though it'll do what you want. https://github.com/skuroda/Sublime-AdvancedNewFile. Take a look at ANF: Rename File int he command palette. You can create a keybinding if necessary. Note that right now there is a bug with ST2 and Windows, that I'll fix a bit later today. I have what I believe will work on the dev branch of the plugin, just need to test it before I pull it into the master branch.
Our team of 4 currently uses svn, but I am testing out Mercurial. We code mostly in C++ and C# on .net. I have installed TortoiseHg, and use hgsubversion to push/pull against the existing svn repo. Other developers on the team will remain on svn for now.
I tend to have a few source files that I have customized (butchered would be a better term) in some specific way that I don't want to push to other developers. But I do want these custom changes compiled into my version of the project. The ratio of normal files to customized files is about 100:1
What is the best way to deal with these butchered files in mercurial? I could simply uncheck butchered files during commits, but eventually, I will forget this step. I have taken a brief look at shelving and ignoring.
Ignoring doesn't seem right, because these are tracked files. I do want to pull changes to butchered files from others. Shelving was close, but it removes the butchered code from my working copy, so that isn't correct either.
I can't be the only code butcher out there. Let me know how you deal with this. Git users, we are happy to hear from you too, we haven't entirely committed to using hg.
If they're files most everyone will be modifying (per developer database account info, etc.) the right way to do it is by tracking a xxxxx.sample file. For example have the build script use local-database.config which is in the .hgignore and provide a local-database.config.sample file in the repository. You can either include "copy the sample to the actual" in your instructions or have the build script do it automatically if the actual doesn't already exist. We have our config do a include of settings.local if and only if it exists, and allow it to override main settings. Then no one needs a local config, but it can be optionally used to alter anything w/o a risk of committing it.
If they're files that only you will be modifying the best way is to learn Mercurial queues. Then you can pop that changeset with the you-only changes, push to central repo, and then apply it again for your builds. There are various extensions that do similar things (shelve for example), but mq is preferable because you can version the overlay you're popping and applying.
I have some changed files I don't want to commit (e.g. web.config). Before I pull and update to new changesets, I have to shelve them. After the pull & update, I have to unshelve them.
I'm currently using TortoiseHG. Is there any extension which can do this automatically?
I'd suggest something else: instead of always shelving and unshelving, you could use two different config files: one which is part of the repository and contains dummy/example data, and another one which each user really uses locally, which is ignored by Mercurial.
Check out this answer for a more detailed explanation what I mean.
The example I'm giving there is for Visual Studio, and I see from your other questions and answers that you're apparently using .net and Visual Studio, so you can just use my example exactly as written.
In Mercurial, just hg pull -u. Uncommitted changes are merged with the tip. Same result as shelve, pull/update, unshelve. With TortoiseHg a dialog will come up prompting for discard/shelve/merge.
You may get a merge dialog this way but that would be true with the shelving approach because unshelve may have to merge as well. From the command line you won't get a prompt if there are no conflicts. TortoiseHg may have an option to suppress the dialog if there are no conflicts, but I haven't checked.
I would try a few different things with this.
Regarding the Web.config file in particular, you might want to look at using local configuration files for overrides instead of leaving local changes uncommitted. (e.g. referencing an separate file that is in .hgignore). Projects I've worked on in the past did this to separate test/prod configurations from the settings for development, or vice-versa.
I don't think there is any extension which will do this for you, but you might be better off writing a quick batch or powershell script to do this workflow for you. On previous projects, I had a script which would do something similar in that it would do a pull/update/rebase to keep my changes at the tip (I was working with hg against an SVN server which made that important.)
I know I didn't answer your question directly, but I hope this helps!
Direct answer: https://pypi.org/project/hg-autoshelve/
But a dedicated repository for configuration files seems a better idea as suggested by
Christian Specht there
I am working on a new project with three other developers, we are all new to Mercurial.
A post build event is created in Visual Studio 2010 to copy DLLs to a common folder. Each time anyone commits or updates we want to rewrite without considering version or merging. That is, this particular folder overwrite local working copy on each update.
Is it possible?
The conventional wisdom is that you shouldn't be committing build products at all. You version source code not dlls. Those you download during build from your CI system.
That said, if they're all DLLs you can set a custom merger for those:
[merge-patterns]
**.dll = internal:remote
That always uses the "other" version when there's a conflict on .dll files. More details here.
Perhaps mercurial hook is the answer.
It is possible to create post commit or post pull hook which will do some work, in this case copy files to common folder.
However, if you wish to copy file after each build, then mercurial is not the way.
In that case, build tool should copy the necessary files.