What is the use case for this behavior, which has made my work unavailable from one location to the next on a dozen occasions? Why is hg like this? How am I "not in the know"?
Hg behaves like svn in this case: it only tracks the files that were explicitly added with svn add or hg add command.
But eclipse plugins behave differently. Why - you could ask their authors.
Zerkms says it as it is - the Eclipse plugin follows the Mercurial standard behaviour.
However, you can enable the option 'preselect tracked files in commit dialog' in the preferences to get default-to-add on commit. :)
Related
I created a new Folder
I put some files in it
I created a new Mercurial repository in this Folder
I tried to commit all files using TortoiseHg
Until this Point I did this Scenario quite often.
But this time i get an error message cannot commit without an active Bookmark.
What does this error message mean?
Recently I experimented with extensions in TortoiseHg.
I activated several of them not knowing what they exactly do...
In my case I had to disable the Extension bookflow("implements bookmark-based branching (EXPERIMENTAL)).
Now the commit is working again as it should.
It's a pity that there is no explanation of these extensions in TortoiseHg :-(
Something to note with bookflow is it requires you to have a bookmark. So with this being the case, you would have to disable it to make repo changes without an active bookmark.
A large part of what it was built for was to make bookmarks act more like a feature branch rather than a tag somewhat like in git.
https://backend.bolt80.com/hgdoc/ext-bookflow.html
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
My question is essentially the same as here but applies to mercurial. I have a set of files that are under version control, and one save operation changes quite a lot of files. Some of the resulting changes are important for revision control, and some of the changes are just junk. I can "partition" off the junk into separate files. These junk files need to be part of a basic checkout in order for it to work, but their contents (and changes over time) aren't that important for revision control. Right now I just tell all our developers not to commit these files, but we all forget and it creates a lot of extra baggage in the repository. I don't really like the svn solution proposed because there are quite a lot of files and I want a simple clone to just work without all this extra manual work, so I was wondering if mercurial has a better alternative. It's kind of like hg shelve but not quite, and kind of like ignore, but not quite. Is there some hg extension that allows for this? Can git do it?
Mercurial doesn't support this. The correct way to do it is to commit thefile.sample and then have your developers (or better you deploy script) do a copy from thefile.sample to thefile if thefile doesn't exist. That way anyone can update the example file, but there's no risk of them committing their local changes (say their personal database connect string).
Aha! So TortoiseHG's repository and global settings have an Auto Exclude List where you can define a list of files that will be unchecked by default when the status, commit, and shelve dialogs open. So they still show up, but the user has to check them in order to actually do a commit. The setting is stored in hgrc, but it's under the [tortoisehg] heading so it's not supported by mercurial per se. Nevertheless, it fits my needs.
One solution to this is to use nested tree support (submodule in git), where the "junk" would be put in a different repository (to avoid cluttering the main repo), while enabling checking out the whole thing out in a consistent manner (right version of both repos in sync).
https://www.mercurial-scm.org/wiki/Subrepository?action=show&redirect=subrepos
In git, submodules are one solution to this issue - but they are not that great UI-wise. What I do instead is to keep two completely independent repositories, and using the subtree merge strategy when I need to update the main repo with the junk repo: http://progit.org/book/ch6-7.html
I'm working on setting up a Hudson/Mercurial stack for development. One of the use cases I have is "As a developer, I want to update my local sandbox to a particular build number from Hudson, so I can [fix a bug, debug issues, create a branched version of code, etc.]."
So, if I see build #49 on Hudson, how do I update my local Mercurial repo to the same source code that was used to build #49?
Note: I have looked at Mercurial tags, however they don't seem quite appropriate. They require a commit, so it seems the commits will dirty up the history (each commit by a developer will show a subsequent commit from the tag operation). If this is the best there is, I guess I will have to live with it, but hoping for something better. Would probably still use tags for releases.
Ok, here's the solution I ended up with:
Using the Description Setter Plugin, I set both the success and failing build description to "Mercurial ${MERCURIAL_REVISION}". Turns out the current Mercurial SCM plugin sets this environment variable to the parent changeset id.
I can then look at a build on Hudson, and if so desired, grab the changeset id and do a "hg update " on my local repo to get that revision of code.
Note that in the Mercurial plugin issue tracker there is some talk of changing this to HG_REVISION instead and adding other environment variables, so this may break at some point in the future, but works for me for now.
You can use the keywords extension on the hudson system to update the nodeid into some aspect of the build, possibly including the artifact names. If the Hudson job output artifacts are like: myproject-2010-02-17-2dbf7575fa46.tar.gz you certainly know how to 'hg update' to that point in time.
The keywords extension and maybe a little ant-fu make that easy to do.
How can i check out only a sub directory from mercurial repository? It seems i can only check out the whole repository.
No, you cannot. See the discussion here:
https://www.mercurial-scm.org/wiki/PartialClone
You can't do it. The feature is planned, but not implemented. The previous person gave a nice link to where you can read a discussion about the partial clone feature.
For now, you should just be really careful to divide things up so a repository is a fairly small unit that makes logical sense to manage in one piece. The existence of the ability to have subrepos might help you organize and manage things until that feature exists.
The next best thing is using the Convert extension as discussed here:
https://www.mercurial-scm.org/wiki/ConvertExtension
It's also useful to filter Mercurial repositories to get subsets of an existing one. For example to transform a subdirectory subfoo of a repository foo into a repository with its own life (while keeping its full history), do the following:
echo include subfoo > /tmp/myfilemap
echo rename subfoo . >> /tmp/myfilemap
hg convert --filemap /tmp/myfilemap /path/to/repo/foo /tmp/mysubfoo-repo
This is the same question as How do I clone a sub-folder of a repository in Mercurial? so the answers there and here are going to be same. I'll summarize them:
"It's not possible".
"Convert the original repository to only contain the directory you're interested in" (but it will no longer be possible to push changes from it into the original repository).
"Convert your main repository into several repositories (using the above) and use Mercurial's subrepository feature to make them act like one" (having to use subrepsitories is considered a Mercurial feature of last resort though).
"Clone the whole repo but do a narrow checkout of only a directory" (needs Facebook's sparse.py third-party extension installed).
"Clone only the history (and by extension the contents) of a specified directory" (needs Google's third-party NarrowHG extension on the client and server).
Terminology notwithstanding (the original question was asking about only "check out" which can only happen after cloning in Mercurial but Subversion doesn't really have the concept of cloning) the NarrowHG solution is arguably the closest to what was desired.