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

Re: Cherry picking merges vs. SVN log -g

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-06-04 16:19:30 CEST

Stefan.Fuhrmann@etas.de wrote:
> Hi @dev,
>
> as I understand, svn log -g will include the tree
> of merge source revisions in its output. Will those
> merged revisions be reported with *all* paths
> changed in that revision or just with those
> that affected the merge?
>
> Example. Log w/o merge info (ignore incorrect
> formatting, this is just a "pseudo-log"):
>
> r10: some modification
> M /foo/A.txt
> M /bar/B.txt
>
> r11: merge /bar into /baz
> M /baz/B.txt
>
>
> What of the following will be reported for r11 with
> merge info included?
>
> Variant 1. Full revision info:
>
> r11: merge /bar into /baz
> M /baz/B.txt
>
> r10: some modification
> merged into r11
> M /foo/A.txt
> M /bar/B.txt
>
>
> Variant 2. Used source paths only:
>
> r11: merge /bar into /baz
> M /baz/B.txt
>
> r10: some modification
> merged into r11
> M /bar/B.txt
>
>
> Personally, I would prefer Variant 1 as it makes the
> log caching extensions in TortoiseSVN much easier
> to implement ;)

'svn log -g' will not show any path information (although the
information still gets returned via to the svn_client_log4() api). The
changed path information shown by 'svn log -gv' will include all
modified paths, not just paths affected by the parent merge.

-Hyrum

Received on Mon Jun 4 16:19:48 2007

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

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