On Fri, Aug 28, 2015 at 7:03 PM, Stefan Hett <stefan_at_egosoft.com> wrote:
> It does and that's not quite the problem for me. However what's possible
> to do with SVN are merges like these:
> merge A/B/somefile into A
> absolutely valid operation, but nothing we use here. In cases this is done
> here in our company it's always an incorrect merge (because someone chose
> the wrong destination folder.
> So we want to prevent issues like these, because they can easily result in
> polluting the mergeinfo records.
Don't now how many out there appreciate the 'subtree merge' behavior, but
in our and our clients, a potential scenario of tenths or hundreds of
developers branching&merging at any level of source tree will become a
unmanageable version control system, in addition to a confusing user
experience for the most of developers.
Take a look to this snippet of a unix/bash pre-commit hook, just in case it
Disclaimer: We don´t have any measure of performance of this script. We
simply haven't need to measure it yet.
# Check forbidden mergeinfo paths
TXN_PATHS=$($SVNLOOK changed -t "$TXN" "$REPOS")
# Grep for paths *not* in merge-allowed levels: /trunk,
TXN_PATHS=$(echo "$TXN_PATHS" | grep -Ev "^....trunk/?$" | grep -Ev
"^....branches/release/\w+/?$" | grep -Ev "^....branches/feature/\w+/?$")
for TXN_PATH in "$TXN_PATHS"
ELEM_PATH=$(echo "$TXN_PATH" | cut -c 5-)
MERGEINFO=$($SVNLOOK propget "$REPOS" svn:mergeinfo -t "$TXN"
if [ ! "$MERGEINFO" = "" ]; then fail_forbidden_mergeinfo_path;fi
Received on 2015-09-05 22:58:05 CEST