![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
hg branching
May. 3rd, 2012 10:35 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vlionper 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.
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.