Keyword expansion for $Log$

[Frank Graf <fg...@freenet.de>]

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?


Frank Graf


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Keyword expansion for $Log$

[Max Bowsher <ma...@ukf.net>]

Guido Ostkamp wrote:
> Hello,
>
> On Mon, 23 Aug 2004, [ISO-8859-1] François Beausoleil wrote:
>> The Subversion team believes this keyword is "evil".  This particular
>> keyword does not exist in Subversion.
>>
>> See svn help propset for the supported keywords.
>
> unfortunately the important RCS keyword $Header$ is also not listed on
> the output of this command.
>
> $URL$ is missing the date, author, version info and
> $Id$  is missing the full path (not really useful)
>
> The only way to get the job done is a manual combination of
>
> $URL$ $Author$ $Date$ $Rev$
>
> Why is it that complicated when it could be so easy to have a $Header$ to
> stay compatible to RCS and probably CVS?

Most likely it was accidentally forgotten.

> Also the manual says you have to turn on propsets for each file like in
>
>    svn propset svn:keywords "Id" file
>
> to turn on expansion for "Id". Furthermore you seem to have to checkout
> and checkin again to make this work, even if the file had a $Id$ label in
> its text earlier.

This, however, is quite deliberate. Subversion operates under the philosophy 
of "do not tamper with data unless explicitly authorized".

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Keyword expansion for $Log$

[Bas Mevissen <ml...@basmevissen.nl>]

On Mon, 2004-08-23 at 23:01, Guido Ostkamp wrote:

> Why is it that complicated when it could be so easy to have a $Header$ to 
> stay compatible to RCS and probably CVS?
> 
> Also the manual says you have to turn on propsets for each file like in
> 
>    svn propset svn:keywords "Id" file
> 
> to turn on expansion for "Id". Furthermore you seem to have to checkout 
> and checkin again to make this work, even if the file had a $Id$ label in 
> its text earlier.
> 

And it is a good thing that you need to do that explicitly. One can make
it the default for certain file types by adding

[miscellany]
enable-auto-props = yes

[auto-props]
*.c = svn:keywords "Id"

to the configuration file "~/.subversion/config" of EVERY client that
has access to the repository. It will set the keyword property on all
newly added files. (I'm not sure if this also goes for modified files).

So you have to change all existing files by hand or script.

AFAIK, you cannot make such properties the default on the server with a
configuration option. You can use hooks of course.

Regards,

Bas.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Keyword expansion for $Log$

[Guido Ostkamp <su...@ostkamp.fastmail.fm>]

Hello,

On Mon, 23 Aug 2004, [ISO-8859-1] François Beausoleil wrote:
> The Subversion team believes this keyword is "evil".  This particular 
> keyword does not exist in Subversion.
>
> See svn help propset for the supported keywords.

unfortunately the important RCS keyword $Header$ is also not listed on 
the output of this command.

$URL$ is missing the date, author, version info and 
$Id$  is missing the full path (not really useful)

The only way to get the job done is a manual combination of

$URL$ $Author$ $Date$ $Rev$

Why is it that complicated when it could be so easy to have a $Header$ to 
stay compatible to RCS and probably CVS?

Also the manual says you have to turn on propsets for each file like in

   svn propset svn:keywords "Id" file

to turn on expansion for "Id". Furthermore you seem to have to checkout 
and checkin again to make this work, even if the file had a $Id$ label in 
its text earlier.

Regards,

Guido

Re: Keyword expansion for $Log$

[François Beausoleil <fb...@ftml.net>]

Hello Frank,

Frank Graf wrote:
> One issue I could not get from the documentation is, whether there is 
> replacement to $Log$ keyword replacement of CVS.
[snip]
> Do I have overlooked something?

The Subversion team believes this keyword is "evil".  This particular 
keyword does not exist in Subversion.

See svn help propset for the supported keywords.

Bye,
François



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Keyword expansion for $Log$

[Max Bowsher <ma...@ukf.net>]

Frank Graf wrote:
> Am 24.08.2004 um 2:11 Uhr schrieb Max Bowsher:
>> 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
> message.
> 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
> it.

This very 'freedom' is what I (and I suspect others too) consider to be one 
of $Log$'s most horrible bugs.

>> 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.

I was really suggesting that people use "svn log" as needed most of the 
time, and simply do "svn log > somefile" if they are preparing for a period 
of disconnected working.

>> If you discuss why you currently use $Log$, perhaps we can suggest an
>> alternative.
>
> 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.

More than anything, this is a conflict of philosophies. The general idea 
common around the subversion project is that putting log data in files is a 
flawed solution - because it duplicates log data across multiple file 
whenever there is a multi-file commit, because it places a large block of 
extra text which must be often scrolled past into the text, and because 
people then seem to think they can modify the expanded value of the keyword 
for some reason.

Subversion cannot do exactly what you want it to. Perhaps your working 
practices can adapt to a way of viewing logs which does have these flaws.

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Keyword expansion for $Log$

[Frank Graf <fg...@freenet.de>]

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 
message.
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 
it.


> 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

Re: Keyword expansion for $Log$

[Max Bowsher <ma...@ukf.net>]

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?

* Do we really want to traverse the entire history for every file we 
checkout?

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).




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

Max.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org