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
Related
We are switching to Mercurial. We are have been using SVN for a number of years. I recall reading somewhere that Twitter only have two branches in their source control. A production branch and a dev branch. This I think will suit us because we offer a service and there is only one instance of it running and we control it completely so we dont have to worry about versions. Just bring able to do fixes for production and maybe merge that change into dev if the issue exists in the dev branch too.
Is this approach appropriate for Mercurial? Are there any hidden gotchas that we should be aware of? We plan do follow a more traditional layout with release branches for the one or two products that we have that we retail.
Yes, no gotchas. The most recognized branching model, for both Git and Mercurial, can be found here, which gives an outline of a more complexe structure than you are thinking of using.
And even when your environment continue to grow, mercurial will still be able to handle your changing needs.
Are there any hidden gotchas that we should be aware of?
Yes, they are, if you will have more than one simultaneous tasks in devel you'll get hardly readable and understandable history with a lot of anonymous branches in devel rather fast
Yes, Mercurial achieves fully your approach. May be the workflow you are proposing is this. The Mercurial code or the Python code are some examples of development with really few branches.
In Mercurial the default branch is used as default when cloning, so is usually used as the development branch. Other branches are used as feature or stable branches, but is up to you. Actually for not so long features and issues one may use bookmarks on the development branch.
And remember to commit often :)
I've used Mercurial for years locally, but now we are doing a pilot of switching over from Subversion at my company.
We're embracing the fact that developers will now be making more granular changesets--some of which may not even build. When developers push their changes to the central repository, all of these changesets will show up in the history - this is natural and expected.
My question is: how do we deal with the fact that, because changesets are more granular, this makes it possible for developers to update to a revision that doesn't build? We are coming from a world where you can checkout anywhere in the repository and reasonably expect to be able to make a release from that point. With DVCS's, how do you tell where a "safe" revision is?
This issue is somewhat addressed in this question, but I'm more interested in finding out how to deal with this using branch repos (and not named branches).
I understand there are ways to modify history (e.g. the collapse extension) so that the changes get collapsed in the history of the repository, but we'd like to preserve the history.
Looking at the mercurial and mozilla trees, I don't see a clear way to tell where safe revisions are to sync. Is this not as important as we think it is?
Do you really need to check out ANY old revision and expect it to build?
I agree with you that you should be able to expect that the tip will always build.
This can be easily achieved, like Lazy Badger already said, by some kind of "don't push unfinished work to the main repo" policy / mutual agreement.
Concerning older revisions:
if you want to build older official releases of your software again (like, you're at version 1.6 now and want to make an v1.2 executable), you can expect the 1.2 tag to build as well if everybody always sticked to the "don't push unfinished work" policy.
if you want to take ANY revision and build it...well, do you really need this? Any bugs in previous versions will probably refer to official releases (see the "1.2 tag" stuff above), and not to something in between.
if you really need a buildable version from in between the official releases (for whatever reason), you'll have to look at the commit messages and find the commit that says feature 'foo' finished (and not the one that says started implementation of feature 'foo').
Yes, this requires a bit of thinking / common sense, but I can't imagine that you will need this really often.
Political solution may be "don't push crap into main repo", isn't it?
Technical solution will be not tag, but one bookmark ("KnownAsGood"), applied to the last working HEAD of default branch and agreement between devs "Update not to tip, but to bookmark"
Who'll test commits and move bookmark is another question from "project management" tag
If you're using feature branches and merging them without fast forward merges, you still have only stable builds on the mainline, but can see the unstable stuff on the feature branches if desired.
You can always tag your commits. These could be major/minor releases, successful builds or however you like. You can see the mercurial and mozilla tags in their repos.
Does anybody have any advice about using Mercurial as a front end for Perforce? What I would like to do is to use Mercurial to handle really granular changes and then, once I'm done something, push it back up to the Perforce server.
I found this article http://www.dehora.net/journal/2008/01/05/using-mercurial-with-perforce/ but it doesn't suggest any tooling to help out with the integrations. Does any exist? I suppose I am looking for it pull any new changes from Perforce, integrate them into my local Mercurial then roll up all the Mercurial commits I've made since last integration and push them up to Perforce. Similar to git-p4.
I got an error when I followed the link you gave. But I suggest you look into the perfarce extension (I love the name!). I have not used it myself, but it's my understanding that this is what people use to bridge the gap between Mercurial and Perforce.
See also the wiki page on Perforce concepts. It seems to have a lot of good info.
As Martin says, Perfarce is what you want. I've used it at a previous job, and in general it works pretty well if you're just working with a single perforce branch into a single mercurial clone. If you start cloning multiple times from your original Mercurial clone, then things start getting complex. Not impossible, just complex.
In general it works by bundling all changes since you last pulled from Perforce. Creating a single perforce changelist from them. Tagging that changelist's comment with the hash of the Mercurial version and committing it to perforce. It then re-imports that change from Perforce and merges it into your Mercurial tree, and because they're both the same there's no merge.
Basically it works quite well for pull/edit/commit/update workflows. Unfortunately it's not any help when it comes to integrations (unless I missed something) as perforce branches aren't converted to Mercurial ones. It wouldn't know what to merge.
Subversion shop considering switching to Mercurial, trying to figure out in advance what all the complaints from developers are going to be. There's one fairly common use case here that I can't see how to handle.
I'm working on some largish feature, and I have a significant part of the code -- or possibly several significant parts of the code -- in pieces all over the garage floor, totally unsuitable for checkin, maybe not even compiling.
An urgent bugfix request comes in. The fix is nice and local and doesn't touch any of the code I've been working on.
I make the fix in my working copy.
Now what?
I've looked at "Mercurial cherry picking changes for commit" and "best practices in mercurial: branch vs. clone, and partial merges?" and all the suggestions seem to be extensions of varying complexity, from Record and Shelve to Queues.
The fact that there apparently isn't any core functionality for this makes me suspect that in some sense this working style is Doing It Wrong. What would a Mercurial-like solution to this use case look like?
Edited to add: git, by contrast, seems designed for this workflow: git add the bugfix files, don't git add anything else (or git reset HEAD anything you might have already added), git commit.
Here's how I would handle the case:
have a dev branch
have feature branches
have a personal branch
have a stable branch.
In your scenario, I would be committing frequently to my branch off the feature branch.
When the request came in, I would hg up -r XYZ where XYZ is the rev number that they are running, then branch a new feature branch off of that(or up branchname, whatever).
Perform work, then merge into the stable branch after the work is tested.
Switch back to my work and merge up from the top feature branch commit node, thus integrating the two streams of effort.
Lots of useful functionality for Mercurial is provided in the form of extensions -- don't be afraid to use them.
As for your question, record provides what you call partial commits (it allows you to select which hunks of changes you want to commit). On the other hand, shelve allows to temporarily make your working copy clean, while keeping the changes locally. Once you commit the bug fix, you can unshelve the changes and continue working.
The canonical way to go around this (i.e. using only core) would probably be to make a clone (note that local clones are cheap as hardlinks are created instead of copies).
You would clone the repository (i.e. create a bug-fix branch in SVN terms) and do the fix from there.
Alternatively if it really is a quick fix you can use the -I option on commit to explicitly check-in individual files.
Like any DVCS, branching is your friend. Branching a repository multiple ways is the bread and butter of these system. Here's a git model you might consider adopting that works quite well with Mercurial, also.
In addition to what Santa said about branching being your friend...
Small-granularity commits are your friend. Rather than making lots of code changes in a single commit, make each logically self-contained code change in its own commit. Then it will be a lot easier to cherry-pick changes to merge between branches.
Don't use Mercurial without using the Mq Extension (it comes pre-packaged in the default installation). In addition to solving your specific problem, it solves a lot of other general problems and really should be the default way that you work (especially if you're using an IDE that doesn't integrate directly with Hg, making switching branches on the fly a difficult way to work).
I'd like to evaluate Mercurial for my working projects. But most of my projects very heavily rely on the presence of svn:externals-like support. I've searched over StackOverflow and googled for corresponding support in Mercurial. All I found is subrepo feature added in Mercurial 1.3, but the page for this feature said:
subrepos are an experimental feature for Mercurial 1.3. So don't do this on mission critical repositories!
I don't want to use something unstable.
Can anybody shed some light on the real status of this feature, and the plans of polishing/finishing it and when it will be called "stable" and ready for mission critical repositories?
The word in the #mercurial IRC channel is that subrepos will continue to work as they do, and support will grow. For example currently the 'hg status' command isn't subrepo aware -- it works, it just doesn't recurse, but that in the future it will be. However, the current behaviors, fileformats (.hgsub and .hgsubstate) will only be changed in backward compatible ways.
So, go ahead and count on it now, and look forward to it getting better.
P.S. As of mercurial 1.4.2 the subrepos can now be subversion repos, so you can use a mercurial parent and a svn kid.
I've had good luck with the feature in my (light) usage of it so far. It's come in handy in two places:
Backing up a tree of unrelated repositories with a single hg pull command.
Tying a project together with specific versions of its dependencies, so that a single hg clone gets buildable source code. This is closer to the typical svn:externals usage.
Here are a couple of the limitations I've seen with it so far:
In case #1 above, you have to commit all subrepos at once. This is only occasionally annoying, as Mercurial (like any DVCS) encourages frequent commits—so most repos aren't left sitting around in an incomplete state to begin with.
Only the most basic Mercurial commands are subrepo-aware: clone, push / pull, update / commit, and perhaps a couple of others.
Extension authors are going to need time to test their extensions against repositories with subrepos.
When the Mercurial team describes the feature as "experimental," they don't mean that it's suddenly going to decide to erase all your data. They just mean that they haven't coded around all the edge cases like name conflicts (e.g., one developer adds a subrepo called README, while another developer adds a text file called README).