>>
> Another argument for you (and kind of addressed in the FAQ): in
> Subversion, logs are NOT file-centric. They are based upon the
> revision. It is not possible to pull the log messages for a single
> file. You can pull the log messages for all revisions in which the
> file in question was edited, but you can't differentiate which
> portions of the log message apply to which file (unless you have a
> strict structure to those log messages).
I think this is an especially strong argument. Neither, is there any
practical sense in checking in each file independently so that each can
have a separate log.
You might also argue that there is fundamental difference between the
revision management that takes place in Subversion and what might really
be their objective which is sensible and useful Configuration Management
information.
Although they might be asking for keyword / log substitution, it would
interesting to understand why it is so important to them and what
problem they are really trying to solve.
Using a tool like Nant, it is a straightforward process to automate the
generation of a revision log, save it to a file, e-mail it, put it in a
database, etc.
I would also advocate for the generation and storage of change lists
and/or change logs as part of a configuration management function. I
have found that these lists, more than any other information, allay the
'nervousness' created by managers about new versions and releases of
software. If they are presented with a change list that clearly and
unambiguously shows what has changed since the 'previous version', they
seem to relax about other 'illogical' requests.
My $.02 as well.
Ken Parrish
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-09-16 16:48:44 CEST