subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trent Nelson <tr...@snakebite.org>
Subject Re: Merge policies
Date Thu, 19 Apr 2012 17:36:22 GMT

On Apr 19, 2012, at 8:38 AM, Stefan Sperling wrote:

> On Thu, Apr 19, 2012 at 12:48:44PM +0200, Stefan Fuhrmann wrote:
>> Hi all,
>> 
>> After having a closer look at merge and discussing it
>> with Julian on IRC, there seems to be no silver bullet.
>> However, we identified a few things that could be changed
>> and set of constellations that make merge harder than
>> it needs to be.
>> 
>> For the first, there will be another post soon. The second
>> boils down to policy. Luckily, SVN has a mechanism to
>> enforce policies: server-side hook scripts. My proposal
>> is to develop a small set of scripts that a user can
>> combine to prevent situations that her life harder than
>> necessary.
> 
> I like the idea of providing pre-commit hook samples that each
> implement a piece of a merge-policy puzzle.
> 
> At elego we often advise customers about branching/merging strategies.
> It is true that virtually every shop has different requirements (i.e.
> there is no silver bullet). This simply stems from the fact that every
> software project is different. At the same time, a lot of shops end up
> using the same or similar strategy and sometimes reinvent the wheel.
> 
> Subversion by itself enforces virtually no restrictions, and adding
> restrictions to the system is often a major part of the work involved
> in getting a production setup up and running. Often restrictions are
> added over time as people repeatedly make mistakes that cause problems.
> 
> Having an officially supported set of high-quality hook scripts in
> our tools/ directory that are documented well and support a wide
> range of use cases in a modular fashion would help a lot. I believe
> many users would be happy to deploy a hook collection that is officially
> maintained by the Apache Subversion project rather than relying on
> self-written or third-party hook scripts.
> 
> I would definitely be interested in contributing, and maybe others
> at elego would, too. I'd be very happy to install "Apache Subversion"
> branded hooks rather then "elego" branded hooks at customer sites and
> share the development effort.
> 
> And maybe Trent can contribute some of his experience, if he has time?

As the spirit of JFDI is so rife before bed, I'm proud to announce enversion 0.0.0: https://github.com/tpn/enversion!

Quick start guide (that I sort-of just tested on my dusty ol' Macbook):

% git clone git@github.com:tpn/enversion.git
% export PYTHONPATH=`pwd`/enversion
% export PATH=$PATH:`pwd`/enversion/bin
% evnadmin          
Type 'evnadmin <subcommand> help' for help on a specific subcommand.

Available subcommands:
    analyze
    create
    disable-remote-debug (drd)
    doctest
    dump-config (dc)
    dump-default-config (ddc)
    dump-hook-code (dhc)
    enable
    enable-remote-debug (erd)
    find-merges (fm)
    fix-hooks (fh)
    root-info (ri)
    run-hook (rh)
    show-config-file-load-order (scflo)
    show-repo-hook-status (srhs)
    show-repo-remote-debug-sessions (srrds)
    show-roots (sr)
    toggle-remote-debug (trd)
    version


If you get that far, take a look at the hasn't-even-been-proof-read-yet quick start guide:
https://github.com/tpn/enversion/blob/master/doc/quick-start.rst



	Trent.


Mime
View raw message