You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Philipp Leusmann <le...@ebcot.de> on 2011/01/10 15:52:52 UTC

One-time keyword substitution

Hi,

is there a way to have svn substitute a keyword only once and then leave 
it at the substituted value?

I would like to create a file which tracks necessary changes to the 
database for each revision.
For example, it would read like this:

Changes for Rev. 123:
CREATE TABLE FOO;
Changes for Rev. $RevOnce$ :
DROP * FROM FOO;


On commit, the file would change to

Changes for Rev. 123:
CREATE TABLE FOO;
Changes for Rev. 124 :
DROP * FROM FOO;


Thus, the next commiter could use a new $RevOnce$ line.

Is this possible at all?

Sincerely,
Philipp Leusmann

-- 

Mit freundlichen Grüßen,

Philipp Leusmann
System Developer

Ebcot Business Solutions GmbH
Kreuzherrenstrasse 2
D-52062 Aachen

Telefon: +49 - (0)241 - 90 06 72 05
Fax:     +49 - (0)241 - 4 09 15 81

http://www.ebcot.de

Reg.-Nr. HRB 116 74, Amtsgericht Aachen. Hauptsitz Aachen
Vertretungsberechtigte Geschäftsführer:
Andreas Hauser, Michael Kalinowski, Oliver Wolff
_______________________________________________________________________________

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die
unbefugte Weitergabe dieser E-Mail sind nicht gestattet.


Re: One-time keyword substitution

Posted by David Weintraub <qa...@gmail.com>.
2011/1/10 Philipp Leusmann <le...@ebcot.de>

> is there a way to have svn substitute a keyword only once and then leave it
> at the substituted value?
>

To get directly to your answer: No, Subversion doesn't do what you want.

There is a whole mess of debate on the value of RCS keywords in both
Subversion and other version control systems.

I come down firmly on the side the RCS keywords are evil and should never be
used. They basically change the source code you've tested and vetted on
commit which can only mean trouble. And all for what? Everything that RCS
keywords do is already in Subversion.

What is this database for? Is this to allow people to see differences
between files in Subversion revisions via a webpage? If so, why not use
either sventon or ViewVC (http://www.sventon.org/ or http://viewvc.org/)
which handle everything for you without the need for a database? If you
want, you can role your own system that parses the various Subversion
commands via PHP or Perl CGI or whatever technology you want on the fly.

What you're trying to do looks like something "svn log" or "svn blame" will
already do. If you really, really need to do this, then the best bet is to
use a post-commit hook that'll update a file or database with the
information you want.


-- 
David Weintraub
qazwart@gmail.com

Re: One-time keyword substitution

Posted by Philipp Leusmann <le...@ebcot.de>.
Hi Thorsten,

thanks for your answer. And as you already have guessed, the file shall 
be used to contain al necessary changes to the database.

The current problem we have, is updating the patch file from 
bugfix-branches and merging it into the trunk and also update it in the 
trunk itself, while having to maintain a valid order to apply the SQL 
patches. My approach was to use the revision number as some kind of index.

Using separate files would be another approach, but it still has the 
problem of naming them properly to form a timeline without much effort 
to recognize the order for the deployer.

Regards,
  Philipp

Am 10.01.2011 16:15, schrieb Thorsten Schöning:
> Guten Tag Philipp Leusmann,
> am Montag, 10. Januar 2011 um 15:52 schrieben Sie:
>
>> On commit, the file would change to
>> Changes for Rev. 123:
>> CREATE TABLE FOO;
>> Changes for Rev. 124 :
>> DROP * FROM FOO;
> Should this become some kind of changelog or is this supposed to be the
> SQL to change your database to reflect the most current version? In
> the latter case, I would suggest another approach: Don't put
> everything in one file but create a directory like "updates" or else
> and store every change needed to the database as one file with a
> version number. Each file can then be documented on it's own. But you
> don't get something like a changelog, in my opinion this should be
> better generated directly from the log, and I wouldn't recommend using
> svn version numbers, but like in applications something more abstract
> that fits your needs.
>
> We for example just number our database scheme like svn does with it's
> content: We have version 1, 2 ... to n of our database, each version
> has it's own update file as the changes needed to get from one version
> to another and is documented using Doxygen/Javadoc-style syntax.
>
> Mit freundlichen Grüßen,
>
> Thorsten Schöning
>


-- 

Mit freundlichen Grüßen,

Philipp Leusmann
System Developer

Ebcot Business Solutions GmbH
Kreuzherrenstrasse 2
D-52062 Aachen

Telefon: +49 - (0)241 - 90 06 72 05
Fax:     +49 - (0)241 - 4 09 15 81

http://www.ebcot.de

Reg.-Nr. HRB 116 74, Amtsgericht Aachen. Hauptsitz Aachen
Vertretungsberechtigte Geschäftsführer:
Andreas Hauser, Michael Kalinowski, Oliver Wolff
_______________________________________________________________________________

Diese E-Mail könnte vertrauliche und/oder rechtlich geschützte
Informationen enthalten. Wenn Sie nicht der richtige Adressat sind oder
diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die
unbefugte Weitergabe dieser E-Mail sind nicht gestattet.


Re: One-time keyword substitution

Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Philipp Leusmann,
am Montag, 10. Januar 2011 um 15:52 schrieben Sie:

> On commit, the file would change to

> Changes for Rev. 123:
> CREATE TABLE FOO;
> Changes for Rev. 124 :
> DROP * FROM FOO;

Should this become some kind of changelog or is this supposed to be the
SQL to change your database to reflect the most current version? In
the latter case, I would suggest another approach: Don't put
everything in one file but create a directory like "updates" or else
and store every change needed to the database as one file with a
version number. Each file can then be documented on it's own. But you
don't get something like a changelog, in my opinion this should be
better generated directly from the log, and I wouldn't recommend using
svn version numbers, but like in applications something more abstract
that fits your needs.

We for example just number our database scheme like svn does with it's
content: We have version 1, 2 ... to n of our database, each version
has it's own update file as the changes needed to get from one version
to another and is documented using Doxygen/Javadoc-style syntax.

Mit freundlichen Grüßen,

Thorsten Schöning

-- 
Thorsten Schöning
AM-SoFT IT-Systeme - Hameln | Potsdam | Leipzig
 
Telefon: Potsdam: 0331-743881-0
E-Mail:  tschoening@am-soft.de
Web:     http://www.am-soft.de

AM-SoFT GmbH IT-Systeme, Konsumhof 1-5, 14482 Potsdam
Amtsgericht Potsdam HRB 21278 P, Geschäftsführer: Andreas Muchow