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

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

From: Steve Povilaitis <stevepov_at_gmail.com>
Date: Tue, 16 Sep 2008 11:21:55 -0400

On Tue, Sep 16, 2008 at 10:48 AM, Parrish, Ken <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?
Received on 2008-09-16 17:22:27 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.