Hey Shamim, this log message violates another policy documented in
our HACKING file:
"One should never need the log entries to understand the current
code. If you find yourself writing a significant explanation in
the log, you should consider carefully whether your text doesn't
actually belong in a comment, alongside the code it explains."
Run 'svn log' on all 7200 revisions; no log message is anywhere near
this long. You've placed *documentation* into the log message, not a
brief summary of changes. Don't do that; instead, put all of this
history/design/docs into real files, like a README file.
Once you've done that, please change the log message for r7223, using
'svn propedit --revprop -r7223'. Cut it back down to normal size.
kellin@tigris.org writes:
> Author: kellin
> Date: Sat Sep 27 22:48:24 2003
> New Revision: 7223
[...]
> * increment-revision
> (added): RPM sets are all marked X.XX.X-1mdk for release versions and
> X.XX.X-XXXX.1mdk for regular builds. Builds on the trunk however, are
> not truly the same as the previously released version. They are unstable
> and have new functionality. This shell script allows such RPM sets to
> be marked preX.XX.XX-1mdk and preX.XX.XX-XXXX.1mdk respectively while
> incrementing the minor release number so that it is OBVIOUS that they
> are prereleases of the next revision and should not be used for production.
>
> This is done for the express protection of the Mandrake RPM users so
> that they do not accidentally mix and match production and non-production,
> and they have a clearer understanding of what version of the software they
> happen to have their hands on.
>
> Currently, everything is built as "dev build" and it is inherently possible
> as I have proven a number of times myself, to mix and match on a production
> server when attempting to use RPMs unless they are clearly demarcated.
>
> If you look back in the list, more clear revisioning for Mandrake users
> was expressly sanctioned, to the end result of avoiding mixups when dealing
> with production releases - all production releases will always behave as if
> they were compiled by a release tarball UNLESS it occurs in the trunk -
> the trunk is not a production release and is automatically therefore, marked
> as a prerelease with additional information when appropriate.
>
> This would imply that you could check out any of the tags/0.29.0 or
> tags/0.30.0 and proceed to compile a fresh release version of subversion.
>
> This process does not apply to versions prior to 0.29.0.
[...]
> * subversion.spec
> (many changes): This main workhorse now has numerous defines at the top
> to standardize building on non-standard Mandrake platforms for Mandrake
> compatible RPM sets.
>
> It also has a new docs package enabled when fop is available.
>
> It also has a new javahl package enabled when the user requests it.
>
> All things in this spec file are designed such that the generated SRPM
> should compile on any Mandrake system.
>
> All things that are optional have been clearly designated in conditional
> sections that can be turned off.
>
> Apache control functions have been added for the server to ensure
> maximum safety during installtion and de-installation.
>
> And finally the IDEAS file is no longer included as part of the
> spec when building for 0.30.0 or higher.
[...]
> * Makefile
> (heavily modified):
>
> The Makefile has undergone significant changes.
>
> Most significantly, all patches are collected at the time the RPM set
> is requested into static text that is packaged with the SRPM, so that
> any subsequent builds will be true.
>
> Optional sections have been added to the beginning to control:
>
> dependent RPM naming
> required versions
> verbosity during build operations
> locations of third-party tools
> options for third-party tools
>
> Also, autodetection of the location of currently available RPMs is checked
> and suggestions offered if a name change would allow a correct compile.
>
> Appropriate default revisions are used for everything that can be made
> to make sense, taking into account whether a build is on the trunk, 0.30.0
> or even 0.29.0.
>
> This entire build directory can be dropped into the 0.29.0, 0.30.0 or the
> trunk and still compile the appropriate version of the subversion RPM set.
>
> The fop building is currently turned off since it is not compiling all
> elements correctly. Once a resolution is determined a doc package will
> also become available. Currently, the raw unassembled docs are provided
> as part of the base package.
>
> The full list of options and names of all Makefile macros will follow in the
> README or possibly as a second document so that transition can take place
> should someone else need to take over ownership.
>
> Lastly a final document will also be presented outlining the structure
> and layout of the subversion.spec file for the same reasons.
>
> Shamim Islam 9/27/03
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Sep 28 15:37:42 2003