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

[fu]

Throwing up a log of a conversation I had with exor674 from before this post was put up. Lightly cleaned up for coherency and to remove unrelated conversation tangents, otherwise presented without comment.


exor674> I (manually) forked the dw-free repo into a repo on bitbucket, and converted all my oauth-related MQ patches to branches

exor674> one thing I am not sure how I am going to handle is when the patches are committed assuming we use the upload patch style. I guess just merge default into the next branch down which should be a no-op merge unless other changes got in the way?
exor674> ( and if I can manage this, I can manage with whatever we work with and will show if we can maybe use bitbucket to host? )

exor674> I think maybe one problem is if you pull/fetch that repo, all my branches will become into your thingy
exor674> with git, if you fetch someone elses repo, you have to explicitly name the branch
Afuna> so with git it's possible to just get the stable branch?
Afuna> but not so with mercurial?
exor674> I mean, if you are doing a lot of things where you PULL the branch to finish it
exor674> you'll have your thingy tainted by ALL their branches
exor674> while with git you should be able to only pull the one branch you want to work with
exor674> or maybe not even track it locally

exor674> see, here's another case when I think hg is bad
exor674> you can't pull my repo into your dw-free w/o screwing up your ability to push to the main repo ( without tainting it from my repo )
exor674> we'd have to pass flattened patches back and forth
exor674> while I *think* with git you could pull my branch locally
exor674> and still successfully work with the live repo
Afuna> oh huh, that seems weird
Afuna> I'd've thought that that was one thing hg would excel in!
Afuna> not doubting you or antyhing, I'm just rather o_o that
exor674> nope
exor674> like I just now have all the branches in mine and accidentally tried to push to the core repo ( which wouldn't happen )
exor674> $ hg push
exor674> pushing to http://hg.dwscoalition.org/dw-free
exor674> searching for changes
exor674> abort: push creates new remote branch 'feature/OAuth-DeepBackend'!
exor674> (did you forget to merge? use push -f to force)

exor674> and remember the MESS when we switched to staging for a while?
Afuna> I thought that was just because we didn't know what we were doing?
exor674> nope. Because we moved off the default braaaanch

exor674> and tip is weird too
exor674> for that, maybe
exor674> because tip is the most recent commit in the rpo
exor674> not the most recent commit on the branch or
exor674> ( HG branching was added as an afterthought, as far as I can tell while it was designed into git? )
exor674> like the hg repo is just a repo
exor674> tags are through a hack
exor674> branches are probably a hack too
Afuna> yeah
exor674> everything's really in the same treeeeeeee
exor674> git branches are real branches


Afuna> hg IIRC was for a while uh. the clone to a different folder as a barncha?
exor674> hg wants you to maintain seperate repo trees
exor674> instead of braaanching


Afuna> I think the v. best way to is to like
Afuna> actually do a walkthrough of
Afuna> "here's how we would develop a feature now"
Afuna> "here's how we think it'd work in git"
Afuna> "here's how we think it'd work in hg"
Afuna> is the most important thing IMO


exor674> the mq process is probably easier then git
exor674> but proper branching can NOT be done in hg
exor674> without making a MESSSS!
exor674> and what if you decided to name a branch develop/FixGreen
exor674> and I named one that too, for something totally different
exor674> we'd have a COLLIIIIISION
exor674> when you pulled mine in to commit it
exor674> with hg

Afuna> mq is fine for personal development, but it's harder for sharing transparently /o\
Afuna> it's possibel to publish the mq repo, but it's one more level of abstraction
exor674> I think with git you could just check out remote/anall/develop/FixGreen
exor674> and not track it locally
exor674> so it'd be totally seperate from *your* develop/FixGreen

exor674> and bitbucket theoretically has pull requests

Afuna> I do wonder if I'm just missing something ,because so many people use mercurial happily
* Afuna side eyes
exor674> maybe we're both missing something
Afuna> yeah maybe :(
Afuna> another reason to mention the flow we have in mind?
Afuna> so that if someone knows something we don't...

exor674> for instance here's a uh
exor674> possibly a popular-used hg repo: https://bitbucket.org/pmetzger/growl/changesets
exor674> looks like there are personal-work branches in the main repo
exor674> here's another one that doesn't branch at all: https://bitbucket.org/snej/murky/overview
exor674> I think it's a case of that you ahve to be CAREFUL in hg not to taint the repo when merging
exor674> but you have to TRY HARD to taint a git repo while merging
exor674> or https://bitbucket.org/lindenlab/ seems to use multiple hg repos instead of branchen -- scroll down to the bottom
exor674> viewer-beta, viewer-development, viewere-release, etc
exor674> and I think the branches being on ALL of those proves my thesis too
that branching produces unfuntimes
exor674> unfun times are unfun!
exor674> and heh YEP
exor674> http://pastie.org/private/gxjhmfchgxdmmva32lwjxw
exor674> and you have to do a commit to close the branches
exor674> or even: http://pastie.org/private/ozutvffnnmf8hdl7o3zwfw
exor674> I do not get what to do in that case
exor674> and see how badly that pollutes the repo


Afuna> does stash work like an unnamed mq?
Afuna> hm. though Id' rather encourage branching than stash, at least in terms of...
Afuna> regular flow, and use stash only for really really quick things

Afuna> oh hmmm http://mercurial.selenic.com/wiki/BranchingExplained
Afuna> yeah looks like you're right there's really no way to...
Afuna> do the branching hting at least not cleanly, in mercurial
exor674> i mean we could maintain a production and development branch
exor674> and get all mergey with it
exor674> but yeah

[vlion]

Okay, I don't know what exor674 thinks real branching is, so I can't really speak to that charge. But I know that we use branches very successfully at $DAY_JOB, and they seem to be real branches keeping lines of development separate, which is their job. We also use ClearCase, which supports renamable/deleteable branches, and is a horrid terror in part due to that.

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.

You don't have *use* the other branches commits, after all. That's the point of working on a branch: you don't see other people's changes, even tho' they may be in the repository. I see no particular problem with 50-100 different branches/bookmarks.


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

Most theoretical problems with DVCS don't wind up happening in real life; either they are too abtruse to happen, or they are socially worked around.

the fundamental question is: what do you WANT to have happen?

[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.