idiots checklist for mercurial with visual studio 2010

Question

So Im a source control idiot so please humor me with this checklist.

I finally decided to use Mercurial + TortoiseHg + (VS2010 + HgSccPackage) + Kiln for my next project

Answer 1

If your project is not controlled by mercurial yet, then you should use "Add to source control" command. Right-click on solution or project file in solution explorer and select the command in context menu. This command will also create a repository at solution/project location if there isn't one.

If you added the project to mercurial outside of Visual Studio, then you need to reload a project in IDE. Otherwise HgSccPackage don't know that the project is controlled.

If the project is controlled, then adding existing or new files to that project from IDE will automaticaly add them to mercurial.

Merge command is available in "Change log" dialog. To do the merge you need to "Update" to Rev1, then select revision you want to merge with (Rev2), and then run "Merge" command using toolbar command or context menu command.

If you think you found a bug in HgSccPackage, then create an issue with steps to reproduce at HgSccPackage issue tracker (http://bitbucket.org/zzsergant/hgsccpackage/issues).

Answer 2

Print this, laminate it and stick it on the wall. I did.

http://secretgeek.net/mercurial_flow.asp

Answer 3

Here's your individual questions, one per section, with my opinion/answer on each.

---

7. When I'm good and ready I go Sync->Push (So this is all good right?

Correct.

The one thing that might differ in this workflow is if there is anyone else also pushing to the same repository. If you have that, at some point someone else has pushed changesets to the repository that you don't have locally. When you try to push yours that would create a branch in the online repository, made visible by multiple "heads" (you should look up that term in Mercurial context if you don't understand what I mean by that.) Generally you don't allow this to happen, so the push will be aborted.

When it aborts, instead you would pull the changesets from the online repository down into your local one, merge your changeset head with the head you just pulled, and then reattempt the push, which would usually succeed (unless you're unlucky and someone else pushed more in the meantime.)

---

As for HgSCC and Add files, I've had problems with HgSCC so i switched to VisualHg - http://visualhg.codeplex.com, specifically because there seems to be something wrong with the 1.52 version of HgSCC regarding new files. If you can't find a solution for it, I would suggest you try out VisualHG.

---

did you forget to merge?

You should merge your changes together, so that you only have one head again. You have 3 in that example screenshot, "added button to form 2", "final commit" and "2nd prj (2)". You should update to the one you consider to be "most of your project", select it, then right-click on one of the other heads and select "Merge with..." in TortoiseHg, and complete the merge and commit. Each such merge+commit would remove 1 head, so you need at least 2 such merges to get back down to 1 head.

---

Kiln and Fogcreek has a different notion on how to handle branches than many others have. They suggest you create a completely different branch repository and work in that, instead of using named branches. A named branch would be akin to you naming the three changesets in your screenshot (the 3 that end with "final commit") as a branch for adding a new form or fixing a big bug.

So instead of doing what you've done here, having 3 heads, the Kiln "way" would be to have 3 clones, each with only the changesets up to their branch head. Basically you would have 1 repo clone with everything up to "added 2nd form", and continuing with "second proj", but the changesets inbetween would not be there. The second clone would have up to "added 2nd form", and then the one extra labelled "added button to form ", and the third would have "added 2nd form", and then the three ending with "final commit".

Of course, in the end, when pushing and pulling to get back to the main repository, you end up with those branches anyway, but they recommend you use branch repositories like that for bigger branches, like adding big features, modules, etc.

---

Im guessing mercurial handles the merging on its own?

Merging in your scenario would only come into play if you have new changesets in both the original repository and in your branch repository clone.

If you have that, pushing from branch repository to original repository (or pulling the other way) would add new heads in your target repository. This is what merging would help you avoid.

In this way, your workflow would like follows:

1. Push all the changes you have to your branch repository (ie. the changesets resulting from the reason you needed the branch repository in the first place, big bugfix, new feature, big rewrite, whatever)
2. Try to push from branch repository to original repository, getting message that this will create heads in the target repository, so you abort that.
3. Pull from original repository down into branch repository. This will create another heads.
4. Pull from branch repository to your local repository, and do the merge here, handling any and all merge conflicts, finally committing your merge changeset
5. Push from local repository back to branch repository
6. Finalize any code reviews you might want to do in Kiln before you make it official
7. Push from branch repository to original repository (note this is the same as step 2, if someone else (or you) have done more work in the original repository in the meantime, jump back to step 3 and repeat)

---

difference between the View History and View Change Log options

The difference is just what you view it on. View History always shows the history for whatever you have selected, be it a file or the solution file itself, ie. just changesets involving that file.

View Changelog views the changeset log for the repository, regardless of what you have selected.