2

Our project has been converted from svn to git. Developers are now using git-svn, but would like to move on to harness more of the power under the hood. Wishlist:

  • powerful branching, e.g topic/feature branches
  • isolation between mainline and staging work on releases, sometimes multiple in parallel.
  • lean & mean and stable Jenkins-CI setup - minimal maintenance (vs changing job config after each release)
  • short iterations, dev team releases to QA every 2 weeks; not necessarily outside
  • multiple products (P1..P3) built from the same sources, released independently; with varying pressure
  • have more casual, non-git users in the "greater-team"...they are S&U:).. but we have to give them svn access to at least 1 branch (trunk). Their contributions is restricted a few dirs, so no much confict risk here.

Would the following strategy work?

  1. develop: the mainline branch where development happens, a'la git-flow
  2. stable product branches: product1 .. product3. One or more of these will get merges from the main line upon dev release. Seems analogous to 'release start 1.4.3' in git flow-but these would be permanent branches. Releases would be tagged here, then merged back to develop. A this point it would be stable, like master in git-flow, just several of them.
  3. stop using git-svn directly - pushing/pulling to a mirror instead. The can also use feature branches, if needed
  4. merge svn/trunk -> develop. Svn would get occasional and isolated check-ins; so planning to automate it by Jenkins job, notifying people if it failed so that can be merged manually
  5. merge develop->svn/trunk: regularly(eg. daily), in batch mode. This is probably the shakiest part (for newbies at least). Planning something like rebase or some reset wizardy
  6. CI setup would be straightforward, eg test and dev builds off the mainline, official product builds off their own product branches

Git-Flow is tempting - mainly as it's nicely described and automated. But it does not seem like a perfect match for my case; mainly due to the potentially parallel releases, multiple product lines, and CI aspects.

Any informed opinions would be greatly appreciated.

Community
  • 1
  • 1
inger
  • 19,574
  • 9
  • 49
  • 54

1 Answers1

3

Well, once you convert to git it would be pretty hacky to get some branches set up for SVN. I'd argue those "users" should learn or go away. If you need the features of git to do better branch management, then it's the right solution regardless of the S&U.

In terms of managing multiple production releases, I'll offer you the model that I came up with for Net-SNMP that works very well. We have a number of production version branches that are maintained for a number of years and thus tracking patches was always a pain under SVN. Under our new Workflow, we're much much happier and generally have sufficiently good feelings that we didn't drop patches to some branch or another because of real merging (as opposed to SVN where we had to manually make sure every branch contained each patch).

Wes Hardaker
  • 21,735
  • 2
  • 38
  • 69
  • On svn->git syncing (point 4), again: it sounds straightforward: a simple merge. The other way around(#5) is less so - need to make history linear.. It's essentially the same as git-svn (where I used to do complex merging as well) just at a team level. The key, IMHO, is to do it regularly and consistently. What kind pain would you expect - aside from politics? (even if I agree that people should be happy to learn, they can argue that this don't have time right now, and I'd prefer gradual rollout anyway, and not to mix in politics). – inger Mar 05 '12 at 22:07
  • Thanks for sharing your workflow, cascading release branches and waterfall merges are interesting, even if not applicable to my context. In your case the release branches seem to be for maintenance purposes, in mine they are more for parallel rollout/hardening + to provide a clean, product-focused history. – inger Mar 05 '12 at 22:17
  • If your branches are truly parallel, then consider using feature branches as much as possible and having a list of which features need to go into which product branches, etc. – Wes Hardaker Mar 05 '12 at 22:22
  • Basically they would get all features at some point, just in a -potentially- different cycle.. Eg. when P1-V1.4 is being rolled out (stabilisation phase) then we want to protect the P1 branch from work related to P3-V1.7 or general groundwork, however it would get them ASAP (eg. next iteration). BTW the software architecture is modular(OSGi), so just having a single source doesn't mean all products builds will include all features.. but the source does. – inger Mar 05 '12 at 22:35