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_at_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.
Received on 2012-04-19 19:37:00 CEST