----- Original Message -----
From: "Bob Bradley" <email@example.com>
To: "C. Michael Pilato" <firstname.lastname@example.org>
Sent: Tuesday, March 09, 2004 22:57
Subject: Re: CVS $Log$ equivalent in Subversion?
> On 3/9/04 7:53 AM, "C. Michael Pilato" <email@example.com> wrote:
> > IIRC, $Log$ has been decreed evil because of the recursion problem
> > that occurs when you actually use the character sequence "$Log$" in a
> > log message, as in "I added the $Log$ keyword to the top of this
> > file."
> It doesn't seem unreasonable to me to require the user to not use $Log$ in
> log messages if $Log$ is being used. There are also other ways to solve
> more cleanly than the way CVS does it. For example, you could have
> like $LogEnd$ that stops $Log$ expansion after it is found and doesn't do
> $Log$ expansion inside a $Log$ .. $LogEnd$ block. $LogEnd$ could have a
> similar recursion effect, but it would tend to be benign because it would
> just stop expanding earlier than it should, which is most likely fine. An
> even simpler way (just off the top of my head) would be something like
> "$Log-Once$ (probably needs a better name) to stop expanding after it.
> Something more general that I've also found useful is something like
> $EndKeywords$. I added this to CVS (but I never raw a response to my
> so scripts that parsed files with keywords (and therefore had keywords as
> part of their content) didn't get expanded after $EndKeywords$ was found.
> This allowed me to have a header at the top with keywords expanded while
> text below was protected from expansion.
In the case of $Log ...$ and $Id ...$ the endmarker is
a single character, the $ sign.
So I can only think of 3 solutions to that problem:
1) disallow the '$' character inside of keywords.
2) escape the '$' character inside of keywords as \$.
3) use a start and end marker that is guaranteed to not-appear
inside the $..$ marker.
emails use this method to split parts of a mail like
(just an example copied from some email - the marker could
ofcourse be shorter/nicer)
*) If a user accidentally duplicates the line with the "boundary"
marker, or deletes it, spit out an error and don't allow commit.
I think solution 1) or 2) go well with the smaller keywords like $Id$ and
while 3) could be a safe solution for large blocks like $log...$.
Also note that if svn would support $log$ it should also prevent/warn users
making modifications to older log messages. Somewhere I've read that
users tend to try to correct typos inside of old $log$ entries etc.
another EUR 0.2
P.S.: svn already has some similar issues with spaces in/and long usernames
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Mar 10 00:20:12 2004