You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@gmail.com> on 2007/05/26 17:18:55 UTC

New merge-sensitive log feature

Hyrum, others.

I made a sample repository for our merge tracking early adopter
program at CollabNet.  You can download a dump file here for testing:

http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=8590&expandFolder=8590&folderID=0

At the same location, you will also find a graphic that visualizes the
repository transactions that are in the repository.  Currently the
last transaction in the graphic has not been committed because I got
some unexpected conflicts and wanted it to be easy for dlr to look at
it.

Anyway, since I had this repository, I figured I would test it with
the new svn log -g feature.  There are some problems with the results.

Ran this command:

svn log -g -r 13 $REPOS/trunk

------------------------------------------------------------------------
r13 | merger | 2007-05-25 20:41:20 -0400 (Fri, 25 May 2007) | 1 line

Merge branch b
------------------------------------------------------------------------
r10 | auser | 2007-05-25 20:34:22 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r13

Added product roadmaps.
------------------------------------------------------------------------
r11 | merger | 2007-05-25 20:38:10 -0400 (Fri, 25 May 2007) | 4 lines
Result of a merge from: r13

Merged branch a
 - Product restructure
 - New roadmaps
 - Had to resolve conflict in products/index.html
------------------------------------------------------------------------
r12 | buser | 2007-05-25 20:40:03 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r13

Rearrange products alphabetically.
------------------------------------------------------------------------

First problem is that the merge sensitive history is in the wrong order.

Second problem is that r10 comes from r11.  So its message should say:

Result of a merge from: r11, r13

Final problem is that I believe there was also an r7 that should have
shown in the history from r11.

If I run this command:

svn log -g -r11 $REPOS/branches/b

I get even crazier results:

------------------------------------------------------------------------
r11 | merger | 2007-05-25 20:38:10 -0400 (Fri, 25 May 2007) | 4 lines

Merged branch a
 - Product restructure
 - New roadmaps
 - Had to resolve conflict in products/index.html
------------------------------------------------------------------------
r9 | copier | 2007-05-25 20:24:07 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11

Create branch b
------------------------------------------------------------------------
r1 | user | 2007-05-25 20:01:05 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Create initial product structure
------------------------------------------------------------------------
r2 | user | 2007-05-25 20:07:03 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Flesh out page content before launch.
------------------------------------------------------------------------
r3 | copier | 2007-05-25 20:09:29 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Create branch a
------------------------------------------------------------------------
r4 | auser | 2007-05-25 20:13:35 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Create page for medium product.
------------------------------------------------------------------------
r5 | copier | 2007-05-25 20:14:33 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Create branch c
------------------------------------------------------------------------
r6 | merger | 2007-05-25 20:16:28 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Merge branch a.  Added medium product.
------------------------------------------------------------------------
r7 | auser | 2007-05-25 20:22:00 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Restructure product pages. Fixed content on product index.
------------------------------------------------------------------------
r8 | user | 2007-05-25 20:23:16 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11, r9

Missing medium product on index.
------------------------------------------------------------------------
r10 | auser | 2007-05-25 20:34:22 -0400 (Fri, 25 May 2007) | 1 line
Result of a merge from: r11

Added product roadmaps.
------------------------------------------------------------------------

I think the output should have just shown r11 and then r10 and r7
which were the two revisions merged.

I know the feature is not done.  I just thought this might help focus
in on some remaining work.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by Mark Phippard <ma...@gmail.com>.
On 6/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark Phippard wrote:
> > On 6/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> >
> >> Ordering should be fixed now.  Because ordering is determined by the way
> >> the revision range is given on the command line ('svn log -r12:15' vs.
> >> 'svn log -r15:12'), we don't have a way to say 'svn log -g -r13', but
> >> reverse the order of the merged revisions.  This is just an observation;
> >> I don't think we really need to do anything about it at this point.
> >
> > I was going from the spec.  I thought we had talked about this and
> > decided it should show the merged revisions in descending order.
>
> We did.  Should merged revisions always be in descending order, or
> should they be in ascending order if the top level revisions are in
> ascending order?  I'm inclined to go with the second method.

I guess as long as it uses descending order when only a single
revision is specified.

> > With the new dumpfile this is the relevant command:
> >
> > svn log -g -r14 $REPOS/trunk
> >
> > question.  Why does this command give such different results:
> >
> > svn log -g -r14 $REPOS
> >
> > Seems like it really makes it go crazy.
>
> Currently, there isn't a whole lot of path-based filtering going on with
> the merged revisions.  If the mergeinfo has something like '/trunk:1-9',
> you'll get all nine revisions, 1-9, as child revisions.  And since every
> copy starts out with something like '/copysource:1-rev_before_copy', we
> end up pulling back *a lot* of data.  That data will need to be
> filtered, not based upon the destination path, but upon the merge source
> path.

But my understanding was that it was not going to look at the property
at that revision, it was going to look at the *change* to the property
at that revision.  Basically, to determine which of the revisions were
merged at that specific revision.  It does not seem like it is doing
this.

> Another reason for the large volume of data, is that by running the
> command on the root of the repository, you're going to get multiple
> copies of some log messages, both the original message, as well as the
> copies of the message pulled in as the result of a merge.  (See
> http://svn.haxx.se/dev/archive-2007-05/0446.shtml for a previous mail on
> the issue.)  This is exacerbated by the fact that we're already pulling
> in extra revisions already due to the first problem.

I remember that message.  In the scenario in that message it made
sense.  In this case, it seems like the problem lies in the way it is
processing the merge history.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Phippard wrote:
> On 6/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> 
>> Ordering should be fixed now.  Because ordering is determined by the way
>> the revision range is given on the command line ('svn log -r12:15' vs.
>> 'svn log -r15:12'), we don't have a way to say 'svn log -g -r13', but
>> reverse the order of the merged revisions.  This is just an observation;
>> I don't think we really need to do anything about it at this point.
> 
> I was going from the spec.  I thought we had talked about this and
> decided it should show the merged revisions in descending order.

We did.  Should merged revisions always be in descending order, or
should they be in ascending order if the top level revisions are in
ascending order?  I'm inclined to go with the second method.

>> > Second problem is that r10 comes from r11.  So its message should say:
>> >
>> > Result of a merge from: r11, r13
>>
>> (Actually, I think it should be r13, r11)
> 
> The spec has it the other way.

Ah, so it does.  I don't remember how much we talked about it when
writing the spec, but I actually like the reverse better.  Doesn't
matter too much, though.

>> The current implementation is checking for merge children on the current
>> path, not the path which was merged from.  r10 was merged into trunk in
>> r13, but it was also merged into branches/a in r11.  I'll need to look
>> at how to retrieve that information, and look at the merged revisions in
>> the context of their original paths.
>>
>> > Final problem is that I believe there was also an r7 that should have
>> > shown in the history from r11.
>>
>> I'm using the updated dumpfile (where r7 is blocked).  Which revision is
>> this for the new diagram?
> 
> In the new diagram, everything after r7 is just bumped up one, because
> I added an r8 that blocks r7.  This also means there is only r10 (r11
> in the new dumpfile).  So it might be worthwhile to hang on to the
> older dumpfile.

Thanks for the heads up.

> With the new dumpfile this is the relevant command:
> 
> svn log -g -r14 $REPOS/trunk
> 
> question.  Why does this command give such different results:
> 
> svn log -g -r14 $REPOS
> 
> Seems like it really makes it go crazy.

Currently, there isn't a whole lot of path-based filtering going on with
the merged revisions.  If the mergeinfo has something like '/trunk:1-9',
you'll get all nine revisions, 1-9, as child revisions.  And since every
copy starts out with something like '/copysource:1-rev_before_copy', we
end up pulling back *a lot* of data.  That data will need to be
filtered, not based upon the destination path, but upon the merge source
path.

Another reason for the large volume of data, is that by running the
command on the root of the repository, you're going to get multiple
copies of some log messages, both the original message, as well as the
copies of the message pulled in as the result of a merge.  (See
http://svn.haxx.se/dev/archive-2007-05/0446.shtml for a previous mail on
the issue.)  This is exacerbated by the fact that we're already pulling
in extra revisions already due to the first problem.

I'll brainstorm about these issues and try to get a workable solution
sometime next week.

- -Hyrum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGYiHfCwOubk4kUXwRAvxWAJ4ziewjXos/3CyK7Vt3U4C/hylwBgCfeOS3
VCT+l0j75/8khfz5HApGMn0=
=E7UN
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by Mark Phippard <ma...@gmail.com>.
On 6/2/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:

> Ordering should be fixed now.  Because ordering is determined by the way
> the revision range is given on the command line ('svn log -r12:15' vs.
> 'svn log -r15:12'), we don't have a way to say 'svn log -g -r13', but
> reverse the order of the merged revisions.  This is just an observation;
> I don't think we really need to do anything about it at this point.

I was going from the spec.  I thought we had talked about this and
decided it should show the merged revisions in descending order.

> > Second problem is that r10 comes from r11.  So its message should say:
> >
> > Result of a merge from: r11, r13
>
> (Actually, I think it should be r13, r11)

The spec has it the other way.

> The current implementation is checking for merge children on the current
> path, not the path which was merged from.  r10 was merged into trunk in
> r13, but it was also merged into branches/a in r11.  I'll need to look
> at how to retrieve that information, and look at the merged revisions in
> the context of their original paths.
>
> > Final problem is that I believe there was also an r7 that should have
> > shown in the history from r11.
>
> I'm using the updated dumpfile (where r7 is blocked).  Which revision is
> this for the new diagram?

In the new diagram, everything after r7 is just bumped up one, because
I added an r8 that blocks r7.  This also means there is only r10 (r11
in the new dumpfile).  So it might be worthwhile to hang on to the
older dumpfile.

With the new dumpfile this is the relevant command:

svn log -g -r14 $REPOS/trunk

question.  Why does this command give such different results:

svn log -g -r14 $REPOS

Seems like it really makes it go crazy.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,
Thanks for putting this together, sorry it's taken me a bit longer to
get to it than expected.  Having some more complex examples definitely
helps to flesh this out.  A few comments below.

Mark Phippard wrote:
> Hyrum, others.
> 
> I made a sample repository for our merge tracking early adopter
> program at CollabNet.  You can download a dump file here for testing:
> 
> http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=8590&expandFolder=8590&folderID=0
> 
> 
> At the same location, you will also find a graphic that visualizes the
> repository transactions that are in the repository.  Currently the
> last transaction in the graphic has not been committed because I got
> some unexpected conflicts and wanted it to be easy for dlr to look at
> it.
> 
> Anyway, since I had this repository, I figured I would test it with
> the new svn log -g feature.  There are some problems with the results.
> 
> Ran this command:
> 
> svn log -g -r 13 $REPOS/trunk
> 
> ------------------------------------------------------------------------
> r13 | merger | 2007-05-25 20:41:20 -0400 (Fri, 25 May 2007) | 1 line
> 
> Merge branch b
> ------------------------------------------------------------------------
> r10 | auser | 2007-05-25 20:34:22 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r13
> 
> Added product roadmaps.
> ------------------------------------------------------------------------
> r11 | merger | 2007-05-25 20:38:10 -0400 (Fri, 25 May 2007) | 4 lines
> Result of a merge from: r13
> 
> Merged branch a
> - Product restructure
> - New roadmaps
> - Had to resolve conflict in products/index.html
> ------------------------------------------------------------------------
> r12 | buser | 2007-05-25 20:40:03 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r13
> 
> Rearrange products alphabetically.
> ------------------------------------------------------------------------
> 
> First problem is that the merge sensitive history is in the wrong order.

Ordering should be fixed now.  Because ordering is determined by the way
the revision range is given on the command line ('svn log -r12:15' vs.
'svn log -r15:12'), we don't have a way to say 'svn log -g -r13', but
reverse the order of the merged revisions.  This is just an observation;
I don't think we really need to do anything about it at this point.

> Second problem is that r10 comes from r11.  So its message should say:
> 
> Result of a merge from: r11, r13

(Actually, I think it should be r13, r11)

The current implementation is checking for merge children on the current
path, not the path which was merged from.  r10 was merged into trunk in
r13, but it was also merged into branches/a in r11.  I'll need to look
at how to retrieve that information, and look at the merged revisions in
the context of their original paths.

> Final problem is that I believe there was also an r7 that should have
> shown in the history from r11.

I'm using the updated dumpfile (where r7 is blocked).  Which revision is
this for the new diagram?

> If I run this command:
> 
> svn log -g -r11 $REPOS/branches/b
> 
> I get even crazier results:
> 
> ------------------------------------------------------------------------
> r11 | merger | 2007-05-25 20:38:10 -0400 (Fri, 25 May 2007) | 4 lines
> 
> Merged branch a
> - Product restructure
> - New roadmaps
> - Had to resolve conflict in products/index.html
> ------------------------------------------------------------------------
> r9 | copier | 2007-05-25 20:24:07 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11
> 
> Create branch b
> ------------------------------------------------------------------------
> r1 | user | 2007-05-25 20:01:05 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create initial product structure
> ------------------------------------------------------------------------
> r2 | user | 2007-05-25 20:07:03 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Flesh out page content before launch.
> ------------------------------------------------------------------------
> r3 | copier | 2007-05-25 20:09:29 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create branch a
> ------------------------------------------------------------------------
> r4 | auser | 2007-05-25 20:13:35 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create page for medium product.
> ------------------------------------------------------------------------
> r5 | copier | 2007-05-25 20:14:33 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create branch c
> ------------------------------------------------------------------------
> r6 | merger | 2007-05-25 20:16:28 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Merge branch a.  Added medium product.
> ------------------------------------------------------------------------
> r7 | auser | 2007-05-25 20:22:00 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Restructure product pages. Fixed content on product index.
> ------------------------------------------------------------------------
> r8 | user | 2007-05-25 20:23:16 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Missing medium product on index.
> ------------------------------------------------------------------------
> r10 | auser | 2007-05-25 20:34:22 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11
> 
> Added product roadmaps.
> ------------------------------------------------------------------------
> 
> I think the output should have just shown r11 and then r10 and r7
> which were the two revisions merged.

Yeah.  Part of that has to do with the fact that when we create a
branch, the mergeinfo difference shows up as everything upto the
creation of that branch, and so it gets reflected as "merged" when
looking for merge children.

I get similar results on the new dumpfile, but the revisions don't jive.
 Would you mind running the same query on the newer dumpfile and letting
me know what you'd expect?

> I know the feature is not done.  I just thought this might help focus
> in on some remaining work.

Thanks again for the testing and analysis!

- -Hyrum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGYhH5CwOubk4kUXwRAqLvAJ93owQJSguC7KTGfuM+UeozHA1kgQCfQTI7
n95qQ4K/IwrZeJlaVcCqKos=
=WTwS
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark Phippard wrote:
> On 6/6/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
>> Mark,
>> As r25314, of Both of these scenarios should be working.  Let me know if
>> they aren't, or you encounter other problems.
>>
>> -Hyrum
> 
> It is looking pretty good.
> 
> Are you planning on doing more on the JavaHL side?  I started to look
> at how we would integrate this into Subclipse.  I was expecting to see
> something like the LogMessage() class containing an array of
> LogMessage() objects or something like that.

Well, IIRC logMessages() is implemented with a callback interface.  The
messages will come through the callback in an in-order tree traversal.
It is left to the callers to rebuild the tree however they see fit.

That functionality currently isn't implemented, yet, but I can add it
shortly.

- -Hyrum
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGZ1pWCwOubk4kUXwRAiqNAJ98jl5oViQpzfF05RlPXOBnmaA86wCfaYMK
Yl+EgVLaCMCuG9zWC9KrsKM=
=DtuD
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by Mark Phippard <ma...@gmail.com>.
On 6/6/07, Hyrum K. Wright <hy...@mail.utexas.edu> wrote:
> Mark,
> As r25314, of Both of these scenarios should be working.  Let me know if
> they aren't, or you encounter other problems.
>
> -Hyrum

It is looking pretty good.

Are you planning on doing more on the JavaHL side?  I started to look
at how we would integrate this into Subclipse.  I was expecting to see
something like the LogMessage() class containing an array of
LogMessage() objects or something like that.

-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: New merge-sensitive log feature

Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
Mark,
As r25314, of Both of these scenarios should be working.  Let me know if
they aren't, or you encounter other problems.

-Hyrum

Mark Phippard wrote:
> Hyrum, others.
> 
> I made a sample repository for our merge tracking early adopter
> program at CollabNet.  You can download a dump file here for testing:
> 
> http://subclipse.tigris.org/servlets/ProjectDocumentList?folderID=8590&expandFolder=8590&folderID=0
> 
> 
> At the same location, you will also find a graphic that visualizes the
> repository transactions that are in the repository.  Currently the
> last transaction in the graphic has not been committed because I got
> some unexpected conflicts and wanted it to be easy for dlr to look at
> it.
> 
> Anyway, since I had this repository, I figured I would test it with
> the new svn log -g feature.  There are some problems with the results.
> 
> Ran this command:
> 
> svn log -g -r 13 $REPOS/trunk
> 
> ------------------------------------------------------------------------
> r13 | merger | 2007-05-25 20:41:20 -0400 (Fri, 25 May 2007) | 1 line
> 
> Merge branch b
> ------------------------------------------------------------------------
> r10 | auser | 2007-05-25 20:34:22 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r13
> 
> Added product roadmaps.
> ------------------------------------------------------------------------
> r11 | merger | 2007-05-25 20:38:10 -0400 (Fri, 25 May 2007) | 4 lines
> Result of a merge from: r13
> 
> Merged branch a
> - Product restructure
> - New roadmaps
> - Had to resolve conflict in products/index.html
> ------------------------------------------------------------------------
> r12 | buser | 2007-05-25 20:40:03 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r13
> 
> Rearrange products alphabetically.
> ------------------------------------------------------------------------
> 
> First problem is that the merge sensitive history is in the wrong order.
> 
> Second problem is that r10 comes from r11.  So its message should say:
> 
> Result of a merge from: r11, r13
> 
> Final problem is that I believe there was also an r7 that should have
> shown in the history from r11.
> 
> If I run this command:
> 
> svn log -g -r11 $REPOS/branches/b
> 
> I get even crazier results:
> 
> ------------------------------------------------------------------------
> r11 | merger | 2007-05-25 20:38:10 -0400 (Fri, 25 May 2007) | 4 lines
> 
> Merged branch a
> - Product restructure
> - New roadmaps
> - Had to resolve conflict in products/index.html
> ------------------------------------------------------------------------
> r9 | copier | 2007-05-25 20:24:07 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11
> 
> Create branch b
> ------------------------------------------------------------------------
> r1 | user | 2007-05-25 20:01:05 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create initial product structure
> ------------------------------------------------------------------------
> r2 | user | 2007-05-25 20:07:03 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Flesh out page content before launch.
> ------------------------------------------------------------------------
> r3 | copier | 2007-05-25 20:09:29 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create branch a
> ------------------------------------------------------------------------
> r4 | auser | 2007-05-25 20:13:35 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create page for medium product.
> ------------------------------------------------------------------------
> r5 | copier | 2007-05-25 20:14:33 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Create branch c
> ------------------------------------------------------------------------
> r6 | merger | 2007-05-25 20:16:28 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Merge branch a.  Added medium product.
> ------------------------------------------------------------------------
> r7 | auser | 2007-05-25 20:22:00 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Restructure product pages. Fixed content on product index.
> ------------------------------------------------------------------------
> r8 | user | 2007-05-25 20:23:16 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11, r9
> 
> Missing medium product on index.
> ------------------------------------------------------------------------
> r10 | auser | 2007-05-25 20:34:22 -0400 (Fri, 25 May 2007) | 1 line
> Result of a merge from: r11
> 
> Added product roadmaps.
> ------------------------------------------------------------------------
> 
> I think the output should have just shown r11 and then r10 and r7
> which were the two revisions merged.
> 
> I know the feature is not done.  I just thought this might help focus
> in on some remaining work.
>