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.

I read http://hginit.com/ and I played around quite a bit, but I don't know much about source control so I don't want to make a mistake here, my current project is my biggest and most valuable one yet.

So here is my checklist:

Creation:

1. I create a new repo in kiln online.
2. Then clone it on my pc.
3. I copy my entire project folder (Solution with mutiple projects under that folder) into the repo.
4. I add this content into a .hgignore file in the repo root.
5. From TortoiseHg I click add files
6. I occasionally commit from VS.
7. When I'm good and ready I go Sync->Push
   (So this is all good right?)

One problem I had here is. I can't find Add Files equivalent in HgScc, I noticed when I added a new files from the VS-IDE, it doesn't have the icon for source control. (Its not added to mercurial?)

So I ended up adding files through the IDE and they didn't have a check. Then after a few commits (and other things I don't remember) I noticed there was an extra branch or something:

And now If I go try to push I get "(did you forget to merge? use push -f to force)". (And yes I hit incoming and I have NO in coming changes)

Anyway,was just a playground, ** I just realized using TortoiseHG ->Add Files everytime I created files from VS fixes things? **(Or is there a better way here?)

Branching:

So Im a little confused about named branching, but Kiln as their own branch/clone thingy. I read instructions here

1. So, Online, I have option that create a "Branch" in Kiln online.
2. Then I will clone this as a new repo locally (as if it were a new repo)
3. I will make my changes, commit, push.
4. Then I'll pull from the MAIN repo and push from my branch repo to the MAIN.

So I'm not really seeing any merge option here, Im guessing mercurial handles the merging on its own? So I'm not seeing the branch from the repository explorer? Is this how its supposed to be done?

Last question, what is the difference between the View History and View Change Log options and what hg options do they correspond to?:

---

Update: Forgot to mention I'm the only lonely developer on this project. =P

Answer 1

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.