[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Blocking svn:mergeinfo?

From: Kylo Ginsberg <kylo_at_kylo.net>
Date: Tue, 13 Oct 2009 06:49:38 -0700

On Mon, Oct 12, 2009 at 3:28 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.

Close (and for other projects in this repo, I've thought about doing
just what you propose). Here, the team leader realized that the 1.5
best practice is to merge only from project root, but the team members
are accustomed to 1.4-style merging, which did not have this
restriction. Since they don't really care about the downsides I
mentioned above, they'd rather not retrain to 1.5 best practices.
Hence the question of whether there are any other downsides they
should be aware of.

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

OT, but since this recommendation comes up a lot, it would be a nice
enhancement if the CAPS argument passed to the start-commit hook gave
the client version.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-10-13 23:31:15 CEST

This is an archived mail posted to the Subversion Users mailing list.