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

Re: Keyword expansion for $Log$

From: Frank Graf <fgraf_at_freenet.de>
Date: 2004-08-24 06:00:41 CEST

First of all, thank you all for your quick help.

Am 24.08.2004 um 2:11 Uhr schrieb Max Bowsher:

> Frank Graf wrote:
>> Hi,
>> i am currently evaluating whether to replace our current CVS
>> Repository
>> with Subversion.
>> One issue I could not get from the documentation is, whether there is
>> replacement to $Log$ keyword replacement of CVS.
>> Using this you could include the history of the document into it.
>> I did not find such a feature or a different way to achieve this.
>> Do I have overlooked something?
> No, you did not, this feature does not exist in Subversion.
> There have already been responses suggesting to check the archives,
> but since it may be difficult to find the useful info amongst the
> discussion, I'll give a summary:
> In CVS $Log$ was implemented as a messy kludge. Two of the most severe
> resulting bugs are:
> * Lots of merge conflicts
> * If you change a log message, the value in $Log$ doesn't always get
> updated.
> Implementing $Log$ right has a lot of potential pitfalls:
> * What if the log contains "$"? Or even worse, other keywords?

Okay, I see technical problems involved with this and that a developer
can get the same information by using the command svn log, without
causing all this problems.
> * Do we really want to traverse the entire history for every file we
> checkout?
No but CVS found a way, for which they needed only the last commit
Okay, the way $Log$ has been expanded was different than the way used
for other key words and you have now guarantee that it is hundert
percent correct. But on the other side you had the freedom to change

> And also, there is doubt that $Log$ is the right solution:
> * Since revisions generally apply to groups of files, wouldn't a
> seperate logfile be better (assuming that for some reason you can't
> run "svn log" as needed).

But from the users perspective I still think it is very beneficial to
have the history, which lead to this particular file directly
available. So there is no extra action the user had to perform to get
the information. And this information is available even if the source
control system is not available.

It is true that revision generally apply to groups of files. But in
case you are reviewing a certain source file, your starting point is
from this particular file. You want to list all the commit messages
which led to this version of the file.

 From my experience, having developers to maintain a separate log file
by hand or even an log history as a comment in the file, will not work.
It is sad, but it is this way.

> If you discuss why you currently use $Log$, perhaps we can suggest an
> alternative.
> Max.

So what I was looking is an automatic way to include the revision
history into the file without having the developers to do anything.
I hold the $Log$ mechanism of CVS for a goog practical compromise
between automatically getting the information and having the freedom to
modify this information.

Frank Graf

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 24 06:01:09 2004

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.