Migrating from SVN to DVCS.

[Daniel Carrera]

Thanks Philip. That was extremely interesting and informative.

Cheers,
Daniel.

On Friday June 08, 2012 at 2:00 AM, Philip Peitsch <philip.peitsch at gmail.com> wrote:
>
>On 8 June 2012 00:49, Daniel Carrera  wrote:
> Hi Philip,
> Thanks for the info. Very interesting. I do have a follow-up
>question:  What motivated you and your company to switch to Bazaar 
>as
>an SVN client? You know... "what were you trying to accomplish?",
>"what other alternatives did you consider?", etc.
>The primary motivator for using was difficulties with conflicts 
>with
>20 devs all trying to work on a subversion trunk. The project was a
>greenfield project, and many parts of the common stack were
>under-going large amounts of change, and would need to continue to 
>do
>so for the next 3-4months minimum. This was resulting in many
>conflicts during the dreaded update/commit cycle for subversion. 
>All
>it takes is a tree-conflict due to a folder move, and a whole
>day's work can be unrecoverabley lost.
>Bazaar (and DVCS in general) brought the following advantages
> - Better merging from trunk to feature and back. 
> - Easy options to cleanly see what was developed as part of a 
>feature
>before committing (svn makes this part very hard). Code reviews 
>etc.
>possible prior to landing
>  - No more tree conflicts, no more risk to code if a merge goes 
>bad
> - Developer checkpoints, so devs can commit locally often to have
>easy roll-back points for breaking or controversial changes
> - Ability for devs to trade experimental fixes without needing to 
>go
>via trunk or manual patch files
>  - Branching & merging concepts are very easy to use. Command line
>recommends related commands, and provides useful suggestions on
>incorrect syntax. Devs loved this a lot, as it felt like Bazaar was
>helping. Git tends to spit out something obtuse that requires 2-
>3mins
>of googling to figure out...
>Bazaar downsides
> - Memory issues prevent a complete clean checkout of trunk. Linux
>does better due to no memory limits really. Solved this by having
>everyone use the common bazaar repo (as described in the previous
>email)
>  - Bugs as listed previously
>
>We also explored:
> - Subversion branching. Branches and merges to branches are ok. 
>Merging back into trunk tended to break. Merging between branches
>tended to break (tree conflicts). Devs would generally lose a day
>attempting to merge into trunk, and there was a 50% chance of
>re-introducing a fixed bug due to the bad merging. I kept getting 
>told
>that it was a process problem, but none of my 20 devs ever got it
>right over 1.5yrs of trying...
> - Hg. Subversion integration was rudimentary, and not supported in
>core really. Repo setup was easy, but patch queue concept proved
>difficult to introduce to the other devs. Also, no solid Windows 
>UIs.
>Command line UI is nice though (as is Bazaar's)
> - Git. No solid Windows UIs. Complex server setup for a Windows
>environment (ssh keys, specialised hosting servers etc.). Concepts
>were again hard to teach to SVN devs. DVCS devs would have an 
>easier
>time, but SVN guys I find struggled to grasp
>branch/merge/switch/checkout distinctions all DVCSs rely on. Git
>requires exacting knowledge of these to use.
> I am mostly just curious. Interoperability with SVN has a lot to 
>do
>with how easily people can migrate to Bazaar.
> > There seems to be a bzr-svn bridge problem that causes
> > revisions to not maintain consistency between computers, so we
> > would hit issues where we couldnt merge each other's 
>changes,
>and
> > couldnt save or update from trunk.
> Hmm... that's not good.
>
>This has been the major pain as a bzr-svn user. A single bzr user 
>can
>contribute to an SVN trunk happily. But multiple, independent (as 
>in
>no shared central bzr repo) will quickly break each other to the 
>point
>they can no longer commit to trunk.
>Having said that, the up-side of using Bazaar was large enough that
>even my hardened SVN devs were willing to put up with 2 days of 
>down
>time while I figured out how to permanently work around the issue. 
>That is saying a lot for Bazaar's benefits...
> > The solution ended up being a slight workflow adjustment. Rather
>than
> > having developers commit to svn directly from their own machine 
>&
> > own repository, we started requirement them to remote into a
>central
> > shared repository using putty.  Basically, no dev ever directly
>pulled
> > or committed changes from subversion, but rather, they'd all
> > use the shared repo.  This solved the broken repositories and
>changes...
> > and without too many hassles. A bit of developer re-training, 
>but
>it
> > worked well.
> It sounds like you basically migrated entirely to Bazaar... What 
>do
>you use SVN for?
>
>Bazaar doesn't have the necessary integration (or not easy
>integration) with various bits of our tooling stack. We use things
>such as TeamCity, JIRA, an SVN web-interface and some other odds 
>and
>ends that don't have an easy way to talk to Bazaar. 
>Also, we have some very very strict legal requirements on the tools
>we're allowed to use as "authoritative" sources. In this case, 
>we
>had to spend quite a decent amount of time "proving" (with reams of
>paper) that SVN operates as expected within the workflows we use. 
>The
>cost (both time and money) or re-doing this for Bazaar has been 
>beyond
>what the project is willing to spend.  Hence, SVN is needed only 
>for
>the main software "trunk", and is the primary source tree all 
>released
>binaries are built from.
> Cheers,
> Daniel.
>-- 
>Philip Peitsch
>Mob: 0439 810 260