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

[Ben Maurer]

On Tue, 2004-11-16 at 16:36 +0100, Paolo Molaro wrote:
> > 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.

Ok, I found out that handling this is *MUCH* simpler. In the svn-tools
directory is now a little script that will filter out changes only for
the files you query for.

Example of usage:

clview mini.c

You get output like:

r 36062 -- author zoltan
	* mini.c mini-*.h: Get rid of MONO_ARCH_HAVE_RETHROW since all architectures support it now.
	(mini_init): Get rid of it from here too.

r 36060 -- author zoltan
	* mini.c mini-*.h: Get rid of MONO_ARCH_HAVE_RETHROW since all architectures support it now.

r 35966 -- author lluis
	* mini.c: The CEE_ISINST and CEE_CASTCLASS opcodes now take the
	token value as a MonoClass* when compiling a wrapper.
	mono_jit_create_remoting_trampoline now takes an additional
	MonoRemotingTarget parameter.

r35966 is a good example of what is happening here. The changelog in svn
was:

2004-10-26  Lluis Sanchez Gual  <lluis at novell.com>

	* exceptions-ppc.c, exceptions-s390.c, exceptions-s390x.c,
	mini-exceptions.c: handle the new wrapper types.
	* mini.c: The CEE_ISINST and CEE_CASTCLASS opcodes now take the
	token value as a MonoClass* when compiling a wrapper.
	mono_jit_create_remoting_trampoline now takes an additional
	MonoRemotingTarget parameter.

So, i filtered out the changes to unrelated files.

THis script goofs up a bit when people commit bad changelogs, but what
can you expect? You could always use other tools to get the information.

Feel free to add features.

Hopefully this script fulfills (or can be easily fixed to do fulfill)
your desires, so we can start using changesets as we should be. (we
don't have to abandon the ChangeLog file right now, just the
multiple-commits policy -- but I should note that you can view svn log
offline if you use svk on top of svn).

-- Ben