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

[Ben Collins-Sussman]

On Nov 15, 2004, at 4:53 PM, Ben Maurer wrote:
>
> Now that we have switched to a system that has changesets, it seems
> somewhat silly to not use them. The having bigger svn log files (which
> are likely to hold relevant information!) seems a good trade for 
> getting
> changesets.
>

My impression is that Mono project *does* have changesets:  they're 
deduced by looking at the Changelog file.

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 my impression of how things worked with CVS.

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 
the commit (new feature, bugfix, new test, whatever) and then do a 
single commit.  The change needn't just affect file contents either:  
it might include tree changes like copies, renames, deletions, 
additions, and so on.  The resulting global revision number is a 
permanent 'handle' on the change.

When you have a changeset handle, things get really nice:

    * you can close bugs with phrases like "fixed in r23928".
          (this is our standard abbreviation for 'revision 23928')
    * you can revert entire changes at once
    * you can port entire changes at once
    * you can run 'svn log' on the root of a project, and see
      the entire history of a project, rather than use a tool like 
cvs2cl.pl

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.

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.

And besides, the extra information isn't "noise" to be shunned anyway:  
it's valuable data.  A single file rarely gets changed in a vacuum.... 
it's always part of a larger context.  When you ultimately discover 
that 'foo.cs' was broken in r3499, you immediately want to see what 
r3499 was all about, and how the foo.cs change fits into the larger 
spirit of the change.

So the big picture looks like this:

     * A bunch of operations get easier with changeset handles
     * There's no need to manage a separate 'Changelog'.
     * 'svn log' does the job of 'Changelog', but at any resolution you 
want.

Instead of doing all the changeset management yourself, let the system 
do it for you.  Honest.  It works really well.  :-)

<meta>
    Switching SCM systems is never "just" a matter of learning a new 
tool.  It always involves re-evaluating and re-designing your 
development processes too.  We see this over and over again with 
Collabnet's customers.  I just wish you guys had chatted with us about 
this before leaping off the cliff!
</meta>