[Mono-devel-list] Re: [Mono-patches] r36124 - trunk/mono/mono/mini
sussman at collab.net
Mon Nov 15 18:27:30 EST 2004
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
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
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
Instead of doing all the changeset management yourself, let the system
do it for you. Honest. It works really well. :-)
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!
More information about the Mono-devel-list