----- Original Message -----
From: "Bob Bradley" <email@example.com>
To: "C.A.T.Magic" <firstname.lastname@example.org>; "C. Michael Pilato"
Sent: Wednesday, March 10, 2004 00:58
Subject: Re: CVS $Log$ equivalent in Subversion?
> On 3/9/04 3:19 PM, "C.A.T.Magic" <email@example.com> wrote:
> > Also note that if svn would support $log$ it should also prevent/warn
> > from
> > making modifications to older log messages. Somewhere I've read that
> > users tend to try to correct typos inside of old $log$ entries etc.
> Allowing changes to made to the log text in the file is actually an
> important feature. Not necessarily for correcting typos/etc, but because
> is often used to remove old or obsolete logs from the file. For example,
> a file has a major overhaul, it is sometimes useful to trim out the
> irrelevant log entries and leave only the new ones. Or in the case of
> confidential information being in the log text that is exported for public
> viewing. Our open source projects sometimes have to remove this kind of
> from the file so it is safe to release to the public while still giving
> developers a reasonable change history in the file.
changing log entries in just one file will introduce inconsistencies.
afaik, one log entry usually represents the log entry of each 'changeset'
applied to a file. And (at least in cvs) is gets copied to all
modified files. if users modify the $log$ entry of a single file,
svn would/will have to re-scan the $log$ entries for
intended modifications and then replace the changeset logs,
then the next update must redestribute the modified $log$
to all other files that contain the same 'changeset'.
I wouldn't recommend editing the content of $log$ inside a
WC file at all.
If there is need to edit log messages, svn already provides nice features.
If there is need to "trim" old log messages, maybe
something like $Log(startrev=20,endrev=head)...$ could be
added when the $log$ feature is added to svn?
How would differently edited $log$ files react when
merging different revisions? (i can image baad things;-)
But probably you would even need more specific separations,
like some $internallog$ and a $publiclog$ ?
Editing inside of $log$ also has the sideeffect that someone
can maliciously/accidentally modify another persons log entries
which should probably require additional security/permission flags.
i didn't bother to look but CVS mailing lists
probably contain a lot of reasons why not to use/edit it :-)
> 'safe to release to the public'?
I wonder what kind of secrets
you write in those logs? ;-)
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 10 01:24:45 2004