On Mon, Oct 12, 2009 at 4:56 PM, Kylo Ginsberg <kylo_at_kylo.net> wrote:
> I got a proposal today that we block svn:mergeinfo in a pre-commit
> hook for a sub-tree of a repository (a completely self-contained
> sub-tree, i.e. including trunk and all feature/release branches for a
> particular project).
>
> I said that the downsides would be:
> * 1.5+ clients must specify --ignore-ancestry for all 'svn merge' commands
> * clients must use 1.4-style merges, e.g. fully specify revision
> ranges, don't use --reintegrate
> * clients won't see merge info in log/annotate operations, e.g. with a
> 'svn merge log -g'
>
> Does this sound correct? Any other downsides/gotchas? Anyone else
> trying something like this?
It is possible you are misunderstanding the intent in asking for this.
It sounds like they might want a hook to prevent someone from
accidentally committing subtree mergeinfo. Suppose a team leader has
figured out that the "right way" to do a merge is only from the
project root. If a team member forgets and does a merge at a subtree,
this creates subtree mergeinfo and then the whole team has to pay the
price or fix it. So maybe they just want a hook in place to prevent
these commits from happening.
If they do this, my main recommendation is to make sure everyone is
using a new client. Either 1.5.7 or 1.6.5.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2406830
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-13 23:48:02 CEST