Re: log -g problem when performed on files

> That is definitely the way it is expected to work. There is no
> possibility of changing this. Subversion does not really know if a
> commit is the result of a merge,

That's understandable.

> all it can really do is report on changes to the mergeinfo property.

So for my example Subversion doesn't knows at r10 but just at r11 that
changes have been merged so it could report the corresponding revisions
from the branch at r11? (What it currently does not do.)

--
Best regards,
Marc Strapetz
_____________
SyntEvo GmbH
www.syntevo.com
Mark Phippard wrote:
> On Thu, May 8, 2008 at 9:22 AM, Marc Strapetz <marc.strapetz_at_syntevo.com> wrote:
>> When performing log -g on a single file it will return those "Merged via"
>> revisions from the merge sources where the file has actually been changed
>> (and that's great, btw). However, this seems not to work when the
>> svn:mergeinfo property had been committed later than the merge changes
>> itself. For example (using RC5):
> 
> That is definitely the way it is expected to work.  There is no
> possibility of changing this.  Subversion does not really know if a
> commit is the result of a merge, all it can really do is report on
> changes to the mergeinfo property.  The only place this matters is the
> log/blame -g options and they have to assume that the commits where
> the mergeinfo property changes were merges.
> 
> This is also why you cannot take a pre-1.5 repository, set the correct
> mergeinfo properties in HEAD and get working log/blame -g features.
> Merge itself will work properly, but the history commands cannot know
> which revisions were commits if they do not have the mergeinfo
> property modification as part of the commit.
> 
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org