Replacing only long keywords

[Jörg Sommer <jo...@alea.gnuu.de>]

Hi,

I've a problem with keyword expansion. In Latex e.g. constructs like
$Rev$ or $Id$ aren't unusual. Because this I would like to have a switch
to expand only the long form of keywords, because they are much more
uncommon than the short forms, to prevent unintended replacing of this
text.

How do you think about this proposal. The Debian maintainer of subversion
thinks it's not necessary[1], but in a discussion in a german newsgroup
someone agreed me[2].

Regards, Jörg.

PS: Please Cc me because I'm not at the list.

[1] http://bugs.debian.org/322221
[2] news:87d5p0bpxb.fsf@deneb.enyo.de
-- 
Gienger's Law (http://www.bruhaha.de/laws.html):
Die Wichtigkeit eines Newspostings im Usenet ist reziprok zur Anzahl der
enthaltenenen, kumulierten Ausrufungszeichen.

Re: Replacing only long keywords

[Jörg Sommer <jo...@alea.gnuu.de>]

Branko Cibej schrieb am Sat 20. Aug, 11:05 (+0200):
> Jörg Sommer wrote:
> >Can the client detect if the server is ready to handle the changed
> >keywords? Maybe it's possible if a new keyword style is used, the
> >client prints a warning message if the server is not ready.
> > 
> >
> Keywords are expanded by the client, not by the server.

What do you think about having a commandline option 
--replace-only-given-forms, which causes only the forms named in
svn:keywords become expanded.

Bye, Jörg.
-- 
Wer eher stirbt ist länger tot.
    	 	    	       			(Un B. Kant)

Re: Replacing only long keywords

[Branko Čibej <br...@xbc.nu>]

Jörg Sommer wrote:

>What about warning, that the keyword did not became expanded? If you
>specify LastChangedRevision only this is expanded and for all occuences
>of Rev a warning is printed (which can be disabled by a command line
>option).
>  
>
We can't do this.

Lots of people would have to change their svn:keywords on all files, and 
that's unacceptable.

Even ignoring the fact that it would break our compatibility guarantees, 
we'd get flooded by messages about "a bug in keyword expansion".

>Can the client detect if the server is ready to handle the changed
>keywords? Maybe it's possible if a new keyword style is used, the
>client prints a warning message if the server is not ready.
>  
>
Keywords are expanded by the client, not by the server. The server 
doesn't care about the svn:keywords property

-- Brane


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

Re: Replacing only long keywords

[Jörg Sommer <jo...@alea.gnuu.de>]

Kalle Olavi Niemitalo schrieb am Thu 18. Aug, 07:48 (+0300):
> It looks like Jörg Sommer would want to have a way to expand
> $LastChangedRevision$ without expanding $Rev$.

Yes.

> If this feature were added, how would one trigger it?  My first
> thought was to make each alias expand only if it was explicitly
> listed in svn:keywords; one would have to specify "Rev" to expand
> $Rev$, and "LastChangedRevision" to expand $LastChangedRevision$.
> This would be simple and easy to use, but it would be an
> incompatible change; repository maintainers all over the world
> would have to update their svn:keywords properties before the
> changed Subversion client could be used with their repositories,
> and even then, keywords would not be correctly expanded in
> historical revisions.

What about warning, that the keyword did not became expanded? If you
specify LastChangedRevision only this is expanded and for all occuences
of Rev a warning is printed (which can be disabled by a command line
option).

Can the client detect if the server is ready to handle the changed
keywords? Maybe it's possible if a new keyword style is used, the
client prints a warning message if the server is not ready.

Bye, Jörg.
-- 
Was der Bauer nicht kennt, das frißt er nicht. Würde der Städter kennen,
was er frißt, er würde umgehend Bauer werden.
                                                       Oliver Hassencamp

Re: Replacing only long keywords

[Kalle Olavi Niemitalo <ko...@iki.fi>]

Dale Hirt <da...@sbcltd.com> writes:

> Subversion only expands those keywords which you EXPLICITLY
> tell it to expand.  Check the svn:keyword property on your
> document to see which keywords are expanded.  You can add or
> remove whatever you wish.
>
> Please see the following in the Subversion manual:
> http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.4

The sidebar "Keywords and Spurious Differences" there states:

"Note also that we set the svn:keywords property to "Date Author"
yet the keyword anchor used the alias $LastChangedDate$ and still
expanded correctly."

It looks like Jörg Sommer would want to have a way to expand
$LastChangedRevision$ without expanding $Rev$.  I think this is a
quite reasonable request, and I was actually surprised by the
current behaviour when I was hacking psvn.el to support
setting svn:keywords via checkboxes.

If this feature were added, how would one trigger it?  My first
thought was to make each alias expand only if it was explicitly
listed in svn:keywords; one would have to specify "Rev" to expand
$Rev$, and "LastChangedRevision" to expand $LastChangedRevision$.
This would be simple and easy to use, but it would be an
incompatible change; repository maintainers all over the world
would have to update their svn:keywords properties before the
changed Subversion client could be used with their repositories,
and even then, keywords would not be correctly expanded in
historical revisions.

Other possibilities:

- A client-side configuration or command-line option.  Not good
  because every client of the repository would need the same
  setting in order to avoid corrupting files.

- A new syntax in svn:keywords.  For example, "Date" would expand
  both $Date$ and $LastChangedDate$ like it does now, but
  "$Date$" might expand only $Date$.

- An entirely new property, e.g. svn:keywords2 or
  svn:keyword-aliases.

In any case, this change would have to be coordinated with the
custom keywords patches (issue 890), of which some part has been
scheduled for Subversion 1.3.