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

Re: Detecting merges

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2005-06-16 18:19:39 CEST

On Jun 15, 2005, at 7:02 PM, Russ Brown wrote:

> Olivier Sannier wrote:
>> Russ Brown wrote:
>>> Hello,
>>> Is there any way (other than depending on developers providing
>>> parsable commit logs) of detecting at the hook stage whether a given
>>> commit contains a merge or not?
>>> What I want to be able to do is set a revision property
>>> automatically
>>> in such cases, which I intend to use in other scripts for helping to
>>> calculate required merges (among other things).

> As Ben has already pointed out, that's simply not currently
> possible, which is a shame. In that case, the only solutions I can
> think of are for a hook script to detect the merge from the commit
> comment, or by the user explicitly declaring a commit by some
> interface; both of which are prone to the user forgetting.
> ...how hard would it be to make Subversion set a boolean revprop on
> revisions that contain 'a merge of some sort'? From what I can
> figure, that would require the 'merge' command leaving some sort of
> trace for 'commit' to pick up and apply to the revision. That trace
> would clearly need to be 'reverted' once all merged-files had been
> reverted.

You could write a wrapper script for the svn command that deferred to
the regular svn command for all but "merge" (and it's synonyms).. if
the command completed successfully it could make a revprop in the WC
that contained details about the merge command.

Handling a subsequent "revert" before the "commit" could get very
tricky though.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jun 16 18:21:18 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.