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 g...@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.
