On Monday, June 15, 2015 at 7:31:08 AM UTC-7, Paul Seward wrote: > > On 12 June 2015 at 19:14, Ramin K <ramin...@badapple.net <javascript:>> > wrote: > >> >> Being somewhat in the middle of a similar conversation at $dayjob >> I believe it's a mistake to focus on the technology rather than the >> outcome. I would focus on workflow, integration, and tooling instead. >> Particularly the local branch per feature or ticket to review board to >> merge to release branch is flexible, powerful, and relatively easy to >> understand. >> > > Having recently been through this (we used to use svn and have migrated to > git) - the workflow/tooling are definitely the thing to focus on when > describing it to management. > > Feature branch based workflow, with code reviewed merge requests (which > can also be queued pending review board approval if that's how you roll) > are an easy sell to management - and a world of pain to manage in svn. > > With git (and a supporting toolset like > github/bitbucket/gitlab/stash/whatever) that branch/merge based workflow is > super easy. > > "You'll find yourself about 900x more agile with git or the like" - >> Binford2k >> > > branching/merging in git is really the killer feature for me. Compared to > svn, branch/merge is almost so easy it's fun! > > Since moving from svn to git, our time-to-fix has gone down, changes are > easier to stage so are more predictable, and we're pushing around 3 times > as many changes through per week than we were able to before. Yet all those > changes are peer reviewed and discussed before they're merged to > production, in a level of detail which just wasn't possible before. > > It's made us more productive at a higher level of quality - and why > wouldn't a decision maker want that? > > Regarding the document linked to by the OP > https://github.com/logicminds/A-Case-For-Git.git - there are some claims > in there which stretch the truth a bit too far for my liking - eg all the > stuff about r10k not working with svn, or that you lock yourself out of > using 3rd party modules without a lot of effort. > > Thanks Paul these points are awesome. I'll be sure to update the doc. To be honest I have never used SVN and R10k. I suppose SVN wouldn't be that much different from a repo perspective when its listed in the Puppetfile. My concern is what happens when you want to mirror all the publicly available modules hosted on github with only a SVN server. Downloading tarballs from github/gitlab does not seem when you have 20+ modules to keep in sync. Not to mention you lose all the commit history when converting from tarball to SVN. I know there is a Git-SVN but I don't think there SVN-Git.
> I've never tried, but I can't see anything technologically that would stop > you from using svn for your local code control and still using r10k to > retrieve 3rd party modules via git - but the document reads like the sky > will fall in if I try. > > When I'm presenting options to management, I generally need an unbiased > assessment of the problem space, a description of what I'm trying to > achieve, and a clear, unbiased assessment of how each of the options > meets/misses those criteria. > > I would suggest starting by defining a desired workflow (eg, problem is > identified, development environment created, change made, change tested, > change queued for approval, fix merged to production) then evaluating how > svn and git meet those requirements in a fair unbiased manner. > > Obviously git will still win in any scenario which involves > branching/merging - but at least you'll have gone about it in a structured > way, and that's hard to argue against. > > -Paul > -- > ---------------------------------------------------------------------- > Paul Seward, University of Bristol > paul....@bristol.ac.uk <javascript:> +44 (0)117 39 41148 GPG Key ID: > E24DA8A2 > GPG Fingerprint: 7210 4E4A B5FC 7D9C 39F8 5C3C 6759 3937 E24D A8A2 > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1566536b-5f3c-451d-b0de-930bec867a3e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
