I would like to use a specific version of Mercurial for plugin reasons. Is there a way I can tell MacHG to use a specific Mercurial version. I know that it comes with its own, but I would like it to use 'mine', basically.
Yes, it's documented in the project's source code:
Replacing the Mercurial version is fairly trivial. Just replace the version of Mercurial in MacHg/LocalMercurial. Ie replace
MacHg/LocalMercurial/mercurial
MacHg/LocalMercurial/hgext
MacHg/LocalMercurial/mercurial-<version>-py2.6.egg-info
With the new version. Be careful to maintain the extensions in hgext which are not in the new version hgext. Eg histedit,
collapse, etc. Moreover you will need to re-apply the patches specific to MacHg to the new version. To find all these differences
you can simply compare MacHg's LocalMercurial with a checked out version of the Mercurial repository updated (to the same version
but not revision as MacHg is currently using). Eg if MacHg was using version 1.9.2 of Mercurial + MacHg patches, then compare
MacHg's LocalMercurial to version 1.9.2 of stock Mercurial to find all of the MacHg patches.
Even though it's possible, this could easily introduce incompatibilities if you're trying to run an older version of Mercurial, which might cause hard-to-diagnose problems. It's likely safer to simply install an older version of MacHg that comes with the version you need.
If you're just trying to update the version of Mercurial MacHg uses to a newer one, consider submitting a pull request, I'm sure they'd appreciate it.
Related
Is there any way to prevent to move back to an older version?
I mean, I want to always do hg up to forward and never to back.
Make use of the hooks which mercurial offers and implement a hook to the update command which compares the desired version with the currently checked-out version. Fail the hook, when the desired version is older than the currently checked-out one. See the docs for the available hooks and some examples.
That said, it might be an undesirable constraint on usage of a VCS. If it is about deployment on a production syste, that's more sane; yet then you do not need to copy the whole repository with its history, but just the current version to the deployment target.
For my purpose of deployment, I only check whether the build is set to be a release build (tag, or manually selected in jenkins) or if it is HEAD of a branch. In those cases I trigger the deployment to production after the build passed regression tests: https://github.com/OpenTTD/nml/blob/master/.devzone/build/jenkins_postbuild.sh
I'm new to Mercurial and I'm a bit confused about how to stash changes like git. I dug into SO and found some use attic extension while others use shelve extension. Are there any reason I should use one instead of the other?. Are they complementary?.
Thanks...
Attic has not been updated since 2011, whereas Shelve is built-in. I was looking at the same thing myself, and decided to avoid Attic due to lack of maintenance.
From Attic wiki:
Shelve ... is almost entirely a subset of attic. In fact attic's hg shelve --interactive is calling 3 methods directly pulled from the hgshelve extension source code
Attic or Shelve is mostly question of habits and personal tastes
You have to explore MQ Extension also: "Git's stash on steriods"
I've been fine in using attic and am happy with it. (We just upgraded from hg version 2.2.2 to 3.7.3 I do not know how well attic works on the later version. Have to report back.)
In a search now I see there is a slightly newer forked version at https://bitbucket.org/sinbad/hgattic
I've got a fork of some Codeplex project. I wish to update my fork with the latest code in the official code (is that the trunk?).
How can I do this?
I'm also using TortoiseHG on Win7 x64.
Thanks :)
The commands are pull (to fetch the remote changes), and update to update your working directory to the most recent changeset.
Since you don't seem very familiar with the way Mercurial works, it would be a very good idea to read some introductory material like:
http://mercurial.aragost.com/kick-start/
http://hginit.com/
https://www.mercurial-scm.org/quickstart
http://hgbook.red-bean.com/read/a-tour-of-mercurial-the-basics.html
I have a rather big class library written in .NET 3.5 that I'd like to upgrade to make available for .NET 4.0 as well.
In that process, I will rip out a lot of old junk, and rewrite some code to better take advantage of the new classes and support in .NET 4.0 (like TPL.) The class libraries will thus diverge, but still be similar enough that some bug-fixes can be done to both in the same manner.
How should I best organize this class library in Mercurial? I'm using Kiln (fogbugz) if that matters.
I'm thinking:
Named branches in one repository, can then transplant any bugfixes from one to the other
Unnamed branches in one repository, can also transplant, but I think this will look messy
Separate repositories, will have to reimplement the bugfixes (or use a non-mercurial-integraded compare tool to help me)
What would you do? (any other alternatives that I haven't though of is welcome as well.)
Note that the class libraries will diverge pretty heavily in areas, I have some remnants of old collection-type code that does something similar to Linq that I will remove, and some code that uses it that I will rewrite to use the Linq-methods instead. As such, just copying the project files and using #if NET40..#endif sections is not going to work out. Also, the 3.5 version of the class library will not be getting many new features, mostly just critical bug-fixes, so keeping both versions equally "alive" isn't really necessary. Thus, separate copies of all the files are good enough.
Edit From #Rudi's answer here, I think what he's saying is this:
Create two branches (or keep one "default" and create another branch for the other path, which would be "default"=.NET 4.0, and "net35"=.NET 3.5 in my case)
Develop them along their diverging paths
When a critical bugfix is found, and this exists in both versions (ie. in both 3.5 and 4.0), and can be fixed in common code, since the 3.5 version won't accrue a lot of new functionality, it means the bug was most likely present in the original version (before I branched)
I thus create another branch, off of the original version (or very close to it), implement my bugfix, and then I merge this tip into both the 3.5 and the 4.0 branches to update them both.
I will have to think about this. It seems merging in Mercurial pulls in the files, not the changes, which means any changes done to the files that needs to be bugfixed, risks being "merged" back to an earlier stage, but I'll have to test it.
I would use two clones for the different environments (=basically two anonymous branches), maybe also with different branch names within each clone. Also I would use a new branch for each bug fix or interchangeable feature, starting as nearest to the branch point as possible, to make merges between the main branches easier. I would try to develop the bug fixes in the 3.5 branch, since it is more likely that bug fixes in the 4.0 tree would cause merge problems due to other changes there (I'm not saying that this approach does not cause any problems).
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.