[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: help me show others that there are valid reasons for not supporting a $log$ keyword!

From: John Allen <john.allen_at_dublinux.net>
Date: Wed, 17 Sep 2008 16:01:03 +0100

Steve Povilaitis wrote:
>
>
> On Tue, Sep 16, 2008 at 10:48 AM, Parrish, Ken <KParrish_at_gomez.com
> <mailto:KParrish_at_gomez.com>> wrote:
>
> >>
> > 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
>
> Thanks Ken,
>
> I plan to advocate for your suggestions. Can you provide some more
> insight into how you would structure a changelog? I'm thinking
> something along the lines of a list of all the files that were changed
> since the last release. Would you also include a diff of those file
> from the previous release?
For each revision from previous release to current release (in reverse
order)
list of files, and log message.

eg.
r15678
Added additional checking around user specified files
src/main/io/
src/main/tests

r15677
Ensure output files are created with the correct permissions
src/main/io/
src/main/tests

.
.
.
.
.

---------------------------------------------------------------------
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-17 17:01:36 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.