You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Nicolai Scheer <ni...@gmail.com> on 2015/05/18 14:59:19 UTC
Obtaining log messages for a diff
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
Trunk of a project gets branched to the branches folder, and tagged from
there on.
We enforce that every commit's message includes a ticket number for
reference.
Currently, I'm trying to solve a seemingly simple task, that is, answer the
question:
"what's new in the release 1.0.1?".
Speaking of code differences I can just compare the two tags "1.0.0" and
1.0.1".
That's exactly the difference in source code that is about to be shipped,
if a switch from 1.0.0 to 1.0.1 takes place.
Now, I'd like to expand the question to "What tickets are involved in these
changes?"
This one gives me a headache. The diff output has no direct connection to
the revisions anymore, which is quite obvious since a single diff can show
the changes of a lot of revisions.
Does anyone have a hint on how to tackle this issue?
Any help is appreciated!
Greetings
Nico
Re: Obtaining log messages for a diff
Posted by Nicolai Scheer <ni...@gmail.com>.
Hi Andreas,
On 18 May 2015 at 19:07, Andreas Stieger <an...@gmx.de> wrote:
> Hello,
>
> On 18/05/15 15:44, Johan Corveleyn wrote:
>> On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
>> <ni...@gmail.com> wrote:
>>> [...]
>>> Currently, I'm trying to solve a seemingly simple task, that is, answer the
>>> question:
>>> "what's new in the release 1.0.1?".
>>> [...]
>> 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
>
> Or... extract the copy sources of the tags:
>
> $ svn log ^/subversion/tags/1.8.12 -r1:HEAD -l1 --stop-on-copy -v
> ------------------------------------------------------------------------
> r1667497 | stsp | 2015-03-18 12:08:02 +0100 (Wed, 18 Mar 2015) | 1 line
> Changed paths:
> A /subversion/tags/1.8.12 (from /subversion/branches/1.8.x:1667489)
> ^^^^^^^
> M /subversion/tags/1.8.12/subversion/include/svn_version.h
>
> Tagging release 1.8.12
> ------------------------------------------------------------------------
> $ svn log ^/subversion/tags/1.8.13 -r1:HEAD -l1 --stop-on-copy -v
> ------------------------------------------------------------------------
> r1667548 | stsp | 2015-03-18 14:36:18 +0100 (Wed, 18 Mar 2015) | 1 line
> Changed paths:
> A /subversion/tags/1.8.13 (from /subversion/branches/1.8.x:1667537)
> ^^^^^^^
> M /subversion/tags/1.8.13/subversion/include/svn_version.h
>
> Tagging release 1.8.13
> ------------------------------------------------------------------------
>
> And then examine the logs between these two copy sources:
> $ svn log ^/subversion/branches/1.8.x -r1667489:1667537
> ^^^^^^^ ^^^^^^^
> Or, rather, increment the first by 1 to exclude the revision of the
> previous tag:
> $ svn log ^/subversion/branches/1.8.x -r1667490:1667537
> ^^^^^^^ ^^^^^^^
>
> Add --xml to the above for scripting. I have implemented this in a
> number of private tools that integrated with issue trackers. Add some
> XSLT for web display and reporting. Also when parsing mergeinfo you can
> get some trunk logs augmented with information about what was backported
> where, and tags attached to a log view.
Thanks for your suggestion!
Unfortunately this is not possible (anymore), because we recently had
to restructure our folders and needed to move tags around.
Now --stop-on-copy stops on the "wrong" copy which renders this
approach unusable.
Greetings
Nico
Re: Obtaining log messages for a diff
Posted by Andreas Stieger <an...@gmx.de>.
Hello,
On 18/05/15 15:44, Johan Corveleyn wrote:
> On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
> <ni...@gmail.com> wrote:
>> [...]
>> Currently, I'm trying to solve a seemingly simple task, that is, answer the
>> question:
>> "what's new in the release 1.0.1?".
>> [...]
> 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
Or... extract the copy sources of the tags:
$ svn log ^/subversion/tags/1.8.12 -r1:HEAD -l1 --stop-on-copy -v
------------------------------------------------------------------------
r1667497 | stsp | 2015-03-18 12:08:02 +0100 (Wed, 18 Mar 2015) | 1 line
Changed paths:
A /subversion/tags/1.8.12 (from /subversion/branches/1.8.x:1667489)
^^^^^^^
M /subversion/tags/1.8.12/subversion/include/svn_version.h
Tagging release 1.8.12
------------------------------------------------------------------------
$ svn log ^/subversion/tags/1.8.13 -r1:HEAD -l1 --stop-on-copy -v
------------------------------------------------------------------------
r1667548 | stsp | 2015-03-18 14:36:18 +0100 (Wed, 18 Mar 2015) | 1 line
Changed paths:
A /subversion/tags/1.8.13 (from /subversion/branches/1.8.x:1667537)
^^^^^^^
M /subversion/tags/1.8.13/subversion/include/svn_version.h
Tagging release 1.8.13
------------------------------------------------------------------------
And then examine the logs between these two copy sources:
$ svn log ^/subversion/branches/1.8.x -r1667489:1667537
^^^^^^^ ^^^^^^^
Or, rather, increment the first by 1 to exclude the revision of the
previous tag:
$ svn log ^/subversion/branches/1.8.x -r1667490:1667537
^^^^^^^ ^^^^^^^
Add --xml to the above for scripting. I have implemented this in a
number of private tools that integrated with issue trackers. Add some
XSLT for web display and reporting. Also when parsing mergeinfo you can
get some trunk logs augmented with information about what was backported
where, and tags attached to a log view.
Andreas
Re: Obtaining log messages for a diff
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, May 21, 2015 at 10:37 AM, Nicolai Scheer
<ni...@gmail.com> wrote:
> Hi Johan,
>
>
> On 19 May 2015 at 15:47, Nicolai Scheer <ni...@gmail.com> wrote:
>> Hi Johan,
>>
>> On 18 May 2015 at 15:44, Johan Corveleyn <jc...@gmail.com> wrote:
>>>
>>> On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
>>> <ni...@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
Re: Obtaining log messages for a diff
Posted by Nicolai Scheer <ni...@gmail.com>.
Hi Johan,
On 19 May 2015 at 15:47, Nicolai Scheer <ni...@gmail.com> wrote:
> Hi Johan,
>
> On 18 May 2015 at 15:44, Johan Corveleyn <jc...@gmail.com> wrote:
>>
>> On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
>> <ni...@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
Re: Obtaining log messages for a diff
Posted by Nicolai Scheer <ni...@gmail.com>.
Hi Johan,
On 18 May 2015 at 15:44, Johan Corveleyn <jc...@gmail.com> wrote:
>
> On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
> <ni...@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
> >
> > Trunk of a project gets branched to the branches folder, and tagged from
> > there on.
> >
> > We enforce that every commit's message includes a ticket number for
> > reference.
> >
> > Currently, I'm trying to solve a seemingly simple task, that is, answer the
> > question:
> > "what's new in the release 1.0.1?".
> >
> > Speaking of code differences I can just compare the two tags "1.0.0" and
> > 1.0.1".
> > That's exactly the difference in source code that is about to be shipped, if
> > a switch from 1.0.0 to 1.0.1 takes place.
> >
> > Now, I'd like to expand the question to "What tickets are involved in these
> > changes?"
> > This one gives me a headache. The diff output has no direct connection to
> > the revisions anymore, which is quite obvious since a single diff can show
> > the changes of a lot of revisions.
> >
> > Does anyone have a hint on how to tackle this issue?
>
> 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!
Thanks!
Greetings
Nico
Re: Obtaining log messages for a diff
Posted by Johan Corveleyn <jc...@gmail.com>.
On Mon, May 18, 2015 at 2:59 PM, Nicolai Scheer
<ni...@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
>
> Trunk of a project gets branched to the branches folder, and tagged from
> there on.
>
> We enforce that every commit's message includes a ticket number for
> reference.
>
> Currently, I'm trying to solve a seemingly simple task, that is, answer the
> question:
> "what's new in the release 1.0.1?".
>
> Speaking of code differences I can just compare the two tags "1.0.0" and
> 1.0.1".
> That's exactly the difference in source code that is about to be shipped, if
> a switch from 1.0.0 to 1.0.1 takes place.
>
> Now, I'd like to expand the question to "What tickets are involved in these
> changes?"
> This one gives me a headache. The diff output has no direct connection to
> the revisions anymore, which is quite obvious since a single diff can show
> the changes of a lot of revisions.
>
> Does anyone have a hint on how to tackle this issue?
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?
--
Johan
Re: Obtaining log messages for a diff
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Nicolai Scheer wrote on Wed, May 20, 2015 at 11:40:49 +0200:
> On 19 May 2015 at 15:51, Mark Phippard <ma...@gmail.com> wrote:
> > Assuming you know the revisions tag in 1.0.0 and 1.0.1 can't you just run
> > svn log on branches/1.0.x and ask for all changes between those two
> > revisions?
>
> Yes, that is the straighforward way. Unfortunately we "broke" this,
> when we restructured our repository and had to move a lot of tags.
> For newly created tags this works - but we needed a universal approach.
You can use --stop-on-copy to determine not only the most recent copy,
but also the one before that (and so on), using peg revisions. You'd
just have to invoke svn multiple times iteratively until you hit the
right copy operation.
The history / location segments APIs should be able to answer this
question in one invocation, but I don't think they're exposed by the
cmdline client.
Re: Obtaining log messages for a diff
Posted by Nicolai Scheer <ni...@gmail.com>.
Hi Mark,
On 19 May 2015 at 15:51, Mark Phippard <ma...@gmail.com> wrote:
> On Mon, May 18, 2015 at 8:59 AM, Nicolai Scheer <ni...@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
>>
>> Trunk of a project gets branched to the branches folder, and tagged from
>> there on.
>>
>> We enforce that every commit's message includes a ticket number for
>> reference.
>>
>> Currently, I'm trying to solve a seemingly simple task, that is, answer
>> the question:
>> "what's new in the release 1.0.1?".
>>
>
> Assuming you know the revisions tag in 1.0.0 and 1.0.1 can't you just run
> svn log on branches/1.0.x and ask for all changes between those two
> revisions?
Yes, that is the straighforward way. Unfortunately we "broke" this,
when we restructured our repository and had to move a lot of tags.
For newly created tags this works - but we needed a universal approach.
Greetings
Nico
Re: Obtaining log messages for a diff
Posted by Mark Phippard <ma...@gmail.com>.
On Mon, May 18, 2015 at 8:59 AM, Nicolai Scheer <ni...@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
>
> Trunk of a project gets branched to the branches folder, and tagged from
> there on.
>
> We enforce that every commit's message includes a ticket number for
> reference.
>
> Currently, I'm trying to solve a seemingly simple task, that is, answer
> the question:
> "what's new in the release 1.0.1?".
>
>
Assuming you know the revisions tag in 1.0.0 and 1.0.1 can't you just run
svn log on branches/1.0.x and ask for all changes between those two
revisions?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/