hg branching

[vlion]

per fu and pau's requests, A POST ON BRANCHING. [insert meme with a post on top of a tree branch]

hg branching falls into one of several models:

- clone branching

clone branching is where to make a line of development you execute an `hg clone`, do your development on that copy, and then push/pull back to the mainline. This has the advantage of being the simplest; it also has the disadvantage of being easy to mislay a given clone or to not correctly annotate what that clone does with a rename. It may also be very funky to get this to work right for a DW dev environment if I remember how those work right.

- bookmark branching

bookmark branching is like git branching. git branching is like hg bookmarks. (circular reference. :-) ) You have a name that you have to manually push/pull. Commits usually advance the name of the bookmark as you might expect. These branches can be deleted. So in order to create a branch...

`hg bookmark vlion_sweet_branch`, and then do your development on it, merging as needed from your mainline branch (which should also be bookmarked to be your stable/test branching). Push out to the server with hg push -B vlion_sweet_branch. They do have to be manually pulled, which hg tends to be a bit reluctant to about exposing to the other users. It never says, "Here are teh new bookmarks!"

Bookmarks can be deleted, which is good if you don't want bookmark names cluttering up your namespace.

You only need 1 repo to do development on with bookmarks; switching between bookmarks is as simple as `hg up bookmark_name`.

- named branching

Named branches are what I use at $DAY_JOB. They are permanent. They are very similar to bookmarks, but merging is a little different; the new branches don't actually merge (I can create graphs if wanted). Named branches do get sent up to the server and automatically downloaded.

These are more appropriate in situations where you want to track what happened when and where.
E.g., release is a named branch I frequently use. `Testing` is another.



---

One approach that seems like a good idea at this time to me is to have a `release` branch, a `test` branch, and a `dev` branch. Patches are developed on bookmarks referencing bug#, splitting off of `dev` until they are done... when the patch is basically done, it's merged into dev. Then when a push seems good, it gets merged by Fu (or other project lead person) into `test` and whatever tests she thinks is good are run... if it's still good, it gets merged to release and is live... if it's bad, then more work on dev is done until it's fixed.

YMMV, and "it seemed like a good idea at the time" doesn't always work out in practice. This sort of approach is fairly enterprise in how it is designed, and might not fully flow with how DW development works.

HTH,
~V'lion

P.S.,
I'm going to be functionally unavailable until Monday to answer questions (travelling), but I will do my best to answer all questions, even if it's a delayed answer.

Comments

[exor674]

One key difference is hg design philosophy is ALL THE COMMITS ARE EVERYWHERE. You don't wind up with private commits after a pull/push in general. I.... don't see the problem with that in an environment where you want to ensure changes don't fall off the map. You *can* push-pull just one branch at a time if you so want, but I've never quite gotten the reasoning behind that.

So I am working on a large feature and a small feature. Fu pulls from my clone to submit them to the main repo. Are you saying that Fu can't easily push the small feature to the repo without pushing my large feature-related commits. Or that she can't do that without having to be insanely careful in the future?

With respect to namespace collisions: Yes, you could go out and name something the same branch. Why would you?

We can't control what all our devs do. What's stopping two devs from sillily naming their branch FixBug? ( Yeah, I know, social fix, but still. People will do silly things. And with mercurial we cannot correct that after the fact ( well, we could just have them extract a diff and commit it that way ( like we have been doing ), but ) -- so we just screwed people who spent ( to them ) a lot of precious time over.


I think one possible assumption here that you have made for our workflow is that it's okay for all developers to have commit bit to the main repo. I cannot speak fully ( I am not one of the powers that be ) , but I don't believe that is going to be possible.

I think another assumption ( with the branching/bookmark workflow ) is that we want all the work showing up in the main repo. Again, I cannot speak for that truthfully, but I don't believe that is wanted.

[vlion]

- Generally, you can't selectively push changesets. You *can* push particular named branches around.

- branch collision. Yes, its possible that you can do that, but for named branches, maybe you dont want devs to create own branches, that's for stuff like vgifts or mega-rework. Throwing thoughts out.

- Commit bit. Yeah, I guess my assumption is there is prod repo and dev repo: all changesets go to dev and code pushes go from dev to prod. Bad assumption, I have a donkey problem? :-)

- all work showing up in dev repo? Uh... yeah. that way it doesn't get lost. seems reasonable to me.

(calling xb95, calling xb95...)

[exor674]

- Commit bit. Yeah, I guess my assumption is there is prod repo and dev repo: all changesets go to dev and code pushes go from dev to prod. Bad assumption, I have a donkey problem? :-)

- all work showing up in dev repo? Uh... yeah. that way it doesn't get lost. seems reasonable to me.

That probably works well in a job setting ( esp. where peoples salaries are on the line ), probably won't in open source project.

I am thinking of cases ( yes, social cases. But screaming at people is harder in OSS ) where someone commits some horrible shit --author "Andrea Nall <my email address>" ( or even in a non-malicious case -- somebody accidentally commits their feature on one of my bookmarks and then a senior dev ( aka me or fu ), whose time would better be spent coding, has to untangle the mess )

My ( maybe slightly more informed, as I know the project ) assumptions as to on what was wanted with our workflow was that each developer would have their own dev repo ( which would have all the changes ), and then we'd pull only the complete and reviewed changesets either into a global dev repo or the prod repo.