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

Re: Obtaining log messages for a diff

From: Nicolai Scheer <nicolai.scheer_at_gmail.com>
Date: Thu, 21 May 2015 10:37:27 +0200

Hi Johan,

On 19 May 2015 at 15:47, Nicolai Scheer <nicolai.scheer_at_gmail.com> wrote:
> Hi Johan,
>
> On 18 May 2015 at 15:44, Johan Corveleyn <jcorvel_at_gmail.com> wrote:
>>
>> On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
>> <nicolai.scheer_at_gmail.com> wrote:
>> > Hi all,
>> >
>> > we run our subversion repository with a rather standard layout, e.g.:
>> >
>> > /trunk
>> > /branches/1.0.x
>> > /branches/1.1.x
>> > /tags/1.0.0
>> > /tags/1.0.1
>> > /tags/1.1.0
>> > /tags/1.1.1
>> >
[how to create release list]
>>
>> In our build system we generate the list of revision numbers that are
>> in 1.0.1 but not in 1.0.0 by asking svn for the "revisions that are
>> eligible for merging from 1.0.1 to 1.0.0" (i.e. anything that's in
>> 1.0.1 that can sensibly be merged into 1.0.0). I.e.:
>>
>> svn mergeinfo --show-revs=eligible $URL/1.0.1 $URL/1.0.0
>>
>> Can you give that a try?
>
> Thanks for your imput. That's indeed a very interesting approach.
> I did run a few tests and this seems to output exactly what I need.
>
> I'll have to check a few edge cases (e.g. comparing current trunk to
> latest release, including backports etc.) but this seems very
> promising!

I knew it couldn't be that easy :(
Comparing to tags originated from the same branch works flawlessly.

But: We often need a, say, forecast on what will be released if the
current trunk will be branched into the next release branch (and
tagged thereafter).

The command looked like this:

svn mergeinfo --show-revs=eligible $URL/trunk $URL/tags/1.0.4

I need to know what has changed on 1.0.x after tagging 1.0.4 (assuming
1.0.5 is and will not be released), as well as everything that
happened in the trunk meanwhile.
The problem here is, that every change from 1.0.x is merged back into
the trunk, thus creating a new revision which itself of course is not
merged back to the release branch. So the mergeinfo lists these
revisions as well. To make the situation even more complicated our
trunk receives merges from different release-branches (e.g. same trunk
for different products). These merges are indeed interesting for the
new release...

Any suggestions? :)
Hopefully I got the description right - even thinking of it makes my
brain hurt ;)

Greetings

Nico
Received on 2015-05-21 10:38:18 CEST

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.