3

I have a application with 3 environments - dev, stage and production. I have a lot of features/bugfixes that have to be independently deployed to stage and production.

The bugfixes and features have usually 2/3 commits.

Currently I use mercurial for my project, but I can't decide which way to go. The best it should be to use named branches, but I don't know it is right for 1/2/3 commits within. I found that grafts look also promising.

So my question is how to version files if I need to be able deploy changes separately?

deem
  • 1,714
  • 3
  • 19
  • 36

2 Answers2

4

You can use any Mercurial branching model (named|anonymous branches, bookmarks, clones) - it's more question of tastes and habits and tasks - with named branches you'll be able easy in future (if|when needed) detect part of history of repo, related to every completed|WIP job (just because unique branch-name is permanent metadata in every changeset, contrary to anonymous /share the same name as parent/ branch or bookmark-driven /history is mixed in common branch with other changes/ fork of history).

Single drawback of intensive usage of named branches is long output of hg branches after some time. I prefer to use named branches just because it give recoverable history of changes and more polished log: instead of repeating changes with grafted changeset I see one merge for each integration of finished task and graph of repository show all merge-targets

Lazy Badger
  • 87,730
  • 7
  • 72
  • 97
  • Do you know how large can be .hg/ directory while there are about 5k branches? I read Mercurial can handle even Nk branches, but does it has any performance affect on clone, merge, update (latest changesets) commands? It seems that git has a better kind of architecture for this project management way. I found also something like http://www.plasticscm.com/features.aspx what has been designed especially for task development and an every feature/bugfix should be a separated branch. – deem Jul 27 '14 at 14:35
  • 1
    @deem - No, I don't know size. Yes, a **LOT OF** branches can and will affect overall performance, but it will be remarkable **after a years** of development and can be solved by splitting repository by age – Lazy Badger Jul 27 '14 at 15:03
2

You should only be deploying to production from the "master" or primary branch. Each bug fix/feature is usually its own branch so that you can verify the behavior independently without affecting the master branch. Once a fix is confirmed, or a feature is complete, it should be merged back into the master branch. In this sense, you should be using graft, whose purpose is to cherry-pick accepted changes from the alternate branch (i.e. your bug fix branch) back into the master branch for deployment. You can't use grafting without branching, and branching is the most appropriate way to test changes to a source code repository so you don't clutter the master branch with meaningless or false commits. Your master branch should be able to be deployed at any time and still function correctly.

sfdcfox
  • 210
  • 5
  • 11
  • It is also possible to have a stage branch and graft from dev to stage. – Steve Barnes Jul 27 '14 at 07:15
  • @SteveBarnes yes, I consider the same, but I don't know that a separated branch for a bugfix would be a better option.? – deem Jul 27 '14 at 07:39
  • 2
    @deem You can graft from any branch to any other branch. Your bugfixes can all exist in their own branch, which is eventually grafted to staging, and finally to your main/master branch. Keeping each bugfix or feature on its own branch lets you diff branches to see the files/lines that were involved in the fix, and you could easily undo a branch purely from diffs/patches. The team I work on now uses branches just to tag releases, unfortunately, but I think isolating fixes would be a far better choice. It lets you keep out half-fixed bugs, etc. – sfdcfox Jul 27 '14 at 08:44
  • Personally I prefer to use feature branches and then tags for releases which are all off either trunk or sometimes a customer variant branch. – Steve Barnes Jul 27 '14 at 08:46
  • I found two ways described here http://mercurial.aragost.com/kick-start/en/tasks/ branch per bug/task looks good and it suppose to be great in connection with grafts, but I would like to see something like this working in live repo. Do you know any? – deem Jul 27 '14 at 10:33
  • @deem I don't know many git repos at all, much less ones with specific attributes. Just randomly wandering around, I found one that appears to do this: https://github.com/basho/riak. However, I don't know really what it does, so... you'll have to read. Anyways, you'll probably need to experiment to find what works best *for you or your team*. Small'ish projects with many developers working on features in parallel will benefit from this design, while larger projects might benefit more from a major-feature/release type branching system. The key is consistency. – sfdcfox Jul 27 '14 at 12:09
  • @deem See this question/answer about [Why does git fast-forward merges by default?](http://stackoverflow.com/questions/2850369/why-does-git-fast-forward-merges-by-default), which actually has an excellent answer describing why you'd use feature branches (and why not), plus relevant links. It's far superior to this paltry answer of mine. – sfdcfox Jul 27 '14 at 12:30
  • 1
    @sfdcfox - link is relevant **only** for Git, while OP use Mercurial – Lazy Badger Jul 27 '14 at 12:57