Migrating from SVN to DVCS.

[Philip Peitsch]

On 8 June 2012 00:49, Daniel Carrera <dcarrera at hush.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20120608/a8c90780/attachment-0001.html>