On Thu, May 21, 2015 at 10:37 AM, Nicolai Scheer
<nicolai.scheer_at_gmail.com> wrote:
> 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 ;)
Hm, indeed, it makes my head spin too :-).
In our company, we always first fix bugs on trunk, and then "backport"
them (by merging the revisions) to existing release branches. The
"eligible mergeinfo" trick always worked flawlessly for us. So maybe
your problem now is caused by merging in the other direction (first
fixing on release branches, and then merging to trunk)? In our case,
the "eligible mergeinfo" is requested along the same direction as how
we normally merge. Maybe that makes a difference?
Example with our workflow:
- Release 1.0.4 is tagged (at some point made from branch 1.0.x).
- bug X is fixed by r123 on trunk.
- r123 is merged from trunk to branch 1.0.x (backporting of fix for
bug X). That creates r124.
So you want to answer two questions:
1) What's new in 1.0.x that's not in 1.0.4? That's answered by "svn
mergeinfo --show-revs eligible $URL/1.0.x $URL/1.0.4".
2) What's new in trunk that's not in 1.0.4? That's answered by "svn
mergeinfo --show-revs eligible $URL/trunk $URL/1.0.4".
At least, I think it is. I must say it's been a while since I've
looked at the scripts we use for that.
--
Johan
Received on 2015-05-23 23:32:18 CEST