[m-rev.] Updated diff for deep profiling.

[Fergus Henderson]

On 29-May-2001, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> On 29-May-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > If interdiff doesn't work, you can produce a relative diff by checking
> > out two fresh copies of the repository (using a tag or date which
> > matches the workspace that you used to produce the diffs, to avoid any
> > new conflicts), applying the old and new diffs that you posted, and
> > then using `diff --recursive'.
> 
> This would produce a diff in which most changes are the result of
> "cvs update", i.e. changes on the trunk between the two dates.

The idea is that you would use the same tag or date for both workspaces.

> And applying
> the old diff to a current workspace would produce conflicts, as you say.

Oh, so you did a cvs update between producing the old diff and
producing the new diff?  And you didn't create a relative diff
before doing the cvs update?  And you didn't backup the workspace
before/after doing the cvs update?
If so, that was a mistake.  Please don't do that again in future.

> > I think it is important to always produce relative diffs for any
> > substantial changes.  IMHO code should not be committed into the
> > repository unless the other members of the group are given the
> > opportunity to review it.  And reposting a 25000 line diff in which
> > some new changes are scattered (like needles in a haystack ;-) does not
> > really give any effective opportunity for review.
> 
> You have been given opportunities already. You can go through your review
> comments and see how they were addressed.
> 
> If it takes someone who makes a change X hours make a diff easier to review,
> and this makes the reviewer complete his task Y hours more quickly, the project
> wins only if X < Y.
>
> Don't insist that Y be optimized regardless of the increase
> in X just because you are the reviewer.

1.  That presumes there is only one reviewer.  But there may be more than one.
    Indeed, since code review is an extremely effective way of reducing
    later maintenance effort, we should be willing to expend significant
    effort to encourage multiple reviewers.

2.  Generally it is easy to optimize Y with little expense in X, so long as
    you do a little bit of up-front thinking about how your code is going to
    be reviewed.

    If, on the other hand, you go ahead and hack away for a few months,
    without thinking about what you can do to ensure that the changes
    will be easy to review, and produce a single huge diff without
    considering whether it could or should be posted in separate parts to
    make it easier to review, and don't bother to backup your workspace
    at appropriate points (like when posting a diff, and [if you've
    already posted a diff] before/after doing a cvs update), making it
    difficult to produce a relative diff, then yes, it will be harder.
    But I don't think we should encourage that -- do you?

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------