[Mono-devel-list] Re: [Mono-patches] r36124 - trunk/mono/mono/mini

[Paolo Molaro]

On 11/15/04 Ben Collins-Sussman wrote:
> In other words, when a Mono developer wants to port a bugfix to a 
> branch, he would read 'Changelog', notice that 5 files were all 
> committed at roughly the same time, and are talking about the same bug. 
>  He'd then know exactly which files (and versions) to port over.  

That's not what happens usually. Usually the same person that did the
change in head will aslo commit the same change to the branch.
I guess the second more common scenario is to read mono-patches
and apply the patches from there, if the merge happens at a later time
(or read the changes from cvs log).
Note that archiving mono-patches is also a poor man's workaround
for cvs' (and, alas, svn's) lack of distributed support, since
we acan access it while disconnected.

> But Subversion already has the ability to manage changesets for you.  
> Instead of doing 5 separate commits (one per file) or 2-3 commits (per 
> directory), you would write one log message for the whole 'concept' of 

Works fine if you care about the concept in the changelog or if you
care more about more detailed change tracking. When I read the log
for a file, I want just the log for that file.
If svn supported per-file commit comments, we'll happily use it
to commit all the change at once. Until then this just makes
the logs unreadable.

> This last point obviates the need for a Changelog at all;  'svn log' on 
> the root of a project *is* the Changelog.  It can be dynamically 
> generated at any time.

Yes, some people do that with cvs, too. We require the changelogs because
that way they are available offline and in the tarballs we distribute.
Maybe you can make svn log work offline like the modern distributed
systems: in that case we might reconsider our changelog policy.

> Ben and Paolo are right, there's a tradeoff here.  When you run 'svn 
> log foo.cs', you get messages describing whole changesets, not just the 
> one file.  But that's exactly why you have such nicely formatted commit 
> messages, right?  So that you can open the 'svn log' output in your 
> emacs and do an incremental search for filenames or symbol names.  It's 
> not very hard to grep stuff out.

Yes, and with changelogs we can do it even offline, which is a win.

>     * There's no need to manage a separate 'Changelog'.

This assumption is wrong, see above.

> Collabnet's customers.  I just wish you guys had chatted with us about 
> this before leaping off the cliff!

Me too. I proposed that the svn supporters did a few weeks of testing, but
it didn't happen.
Once svn implements per-file comment logs and offline svn log it will
be better suited for our development policies and when it will have
a usable svn annotate it will also better support our development practices:-)
Thanks.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better