pll@lanminds.com writes:
> $ svn log -v -r6236:6284 | wc -l
> 448
>
> $ svn log -v -r6284:HEAD | wc -l
> 1614
>
> r6236 was the 24.0 release, and r6284 is 24.2. This *seems* to
> indicate that there was, at the very least, more verbage in the logs
> between 24.2 and HEAD than there was between 24.0 and 24.2, which
> might account for why I had so much "stuff" in my first attempt.
Heh, yes, more verbiage. I bet 50% of that verbiage is kfogel
describing all the changes to cvs2svn.py, the stuff that's not
important enough to mention. :-)
In general, it's really hard to measure "code flux", and I don't like
trying to do so. Measuring verbiage is useless; something slightly
more useful may be just to count the number of commits, or perhaps the
number of files changed. But it's all kinda silly.
> User-visible changes:
> * command line options:
> . new --force option for svn export (r1296)
> . new --force-log for commit, copy, delete, import, mkdir, move (r6294)
> . --force no longer needed for commit
>
> * commands
> . new - svn archive (r6310)
> . changed - syntax 'svn import [PATH] URL'. (r6288)
> . fixed - Run external diff commands using PATH (r6373)
> . fixed - 'svn switch' memory bug (r6296)
> . fixed - 'svn mkdir' coredump.
>
> * python bindings now in -tools
> * allow parent-into-child copies, provided they are not WC->WC. (r6348)
> * fixed - Apache module installation order (issue 1381)
>
> Developer-visible changes:
>
> * Win32 build system
> . new - .vcproj files for svn_config project and APR
> . fixed - SWIG bindings for Win32 (r6304)
> . vcproj generator now works (r6316)
> . swig's generated .c files now dependent on headers in .i files
> . refactored code common to dsp & vcproj into gen_win.py (r6328)
>
> * fixed
> . SEGFAULTs in SWIG bindings
> . potential SEGFAULTs in 'REPORT vcc' backward-compatibility code.
> . mod_dav_svn's autoversioning failure on PUT
> . 'svn switch' memory bug (r6296)
>
> * changed - mailer.py now uses svn_repos_replay()
This is excellent, great job!
I really like the fact that you've started a "new tradition":
including revision numbers next to each bullet. It means people can
go look up the exact log message for a feature or fix.
But in the process, you've also lost a tradition: heretofore, we've
been including issue numbers with each bullet. At least half our
commits are related to issues, in general, and the log messages say
so. So can you add that stuff back in? I'd rather not substitute
revision numbers for issue numbers. Have both, if possible.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 3 17:59:26 2003