It's Time to Fix Subversion Merge

In my article Why Subversion does not Suck, I argued that Subversion fills a need for simplicity and team synchronization.  It also has an advantage handling large files and repositories.  However, there is one thing about Subversion that definitely sucks:  Merging.  It's time to fix Subversion merge.
Use Cases

Many developers move from Subversion to other SCM systems with better merge capabilities, because modern programming workflows require a lot of merges.

Often, teams work with parallel branches or builds, as in these examples:

    When code is ready to release, the developers make a release branch.  Active development continues on the main branch, and bug fixes are merged between the two branches as needed.
    A custom version of the software is maintained as a branch or a copy/fork/clone, with updates and improvements merged from the main branch or repository.
    A development process has builds for each stage of a test-and-release pipeline: development, testing, stabilization and localization, and release.  Changes get passed from one stage to the next.

Subversion can handle the simple parallel case of a development trunk with mostly static release branches. Subversion teams do not use a multi-stage pipeline, because merging to each stage is too much work.

Read more:  assembla
QR:

Posted via email from Jasper-net