[linux-l] Re: VCS

Mike Dornberger Mike.Dornberger at gmx.de
Fr Apr 28 07:19:06 CEST 2006


Hi,

On Wed, Apr 26, 2006 at 09:25:13AM +0200, Steffen Dettmer wrote:
> * Mike Dornberger wrote on Tue, Apr 25, 2006 at 20:12 +0200:
> > (verschieden benamte) Branches oder Tags sind und man an den Tags eben
> > nicht mehr was committed.
> 
> Aber wenn Branches und Tags das gleiche sind, würde das doch heissen,
> dass man an Branches auch nicht mehr commiten kann?

nein, siehe, was ich vorher schrieb: Man vereinbart, daß man hier und da im
Repository nichts mehr ändert - und ohne Hook-Scripts kann das eben auch
jeder mißachten. Du kannst natürlich in den Logs suchen, wo ein Tag das
erste mal angelegt wurde und dann eben diesen Tag in eben dieser (ersten)
Version auschecken.

Man kann aber auch Hook-Scripts benutzen, die bekommen verschiedene Parameter
mit übergeben, je nachdem auch, um was für ein Script es sich handelt. U. a.
auch den gesamten Pfad der Datei und dann kann das Script den Commit eben
ablehnen, wenn da was mit repos/projects/[^/]+/tags im Pfad vorkommt.

Ich glaube, es war ein Phyton-Script, in dem ich das mal ausführlich gesehen
habe. Kann sein, daß das _nicht_ in dem Buch stand, sondern beim
Debian-Paket als Beispiel mit dabei ist. (Nein, ich schau jetzt nicht extra
nach. ;) )

(Sorry, hab ich selbst noch überhaupt nichts mit Hook-Scripts gemacht; siehe
SVN-Buch, da ist's [glaub ich] ausführlich erklärt, was für verschiedene
Hooks es gibt.)

> > Nunja, im Subversion-Buch ist halt angegeben, daß, wenn man es nicht
> > will, es auch nicht geht. Z. B. wenn man etwas _über_
> > Subversion-Keywords schreiben will.
> 
> Ja klar, man kann's abschalten. Ist mindestens bei Binärfiles eine gute
> Idee :)

Hm, kann sogar sein, daß er es bei Binär-Files überhaupt nicht macht.
(Binär-Files = alles, was Property svn:mime-type != text/* hat; das wird
beim ersten Add z. B. automatisch für alle Dateien gesetzt, bei denen
Subversion "riecht" das, es keine Text-Files sind. Für Details: Use the
{docs,source}, Luke!)

> > Vielleicht ein TODO, wie jemand neue Dateien einchecken soll wäre ein
> > anderes Beispiel. 
> 
> Beispiel wofür jetzt?

Dafür, daß man Keyword-Expansion mal nicht möchte. Z. B. Wenn du für
Anfänger ins TODO (OK, eigentlich meinte ich sowas wie README.1st)
schreibst:

"Jedes C-File muß mit folgendem Header beginnen:
/* blahfasel ... licens ...
 * ... has been downloaded from $HeadURL$
 * ... this is revision $Rev$ ...
 */
...
"

> > Oder du schreibst ein Programm, was auch etwas mit diesen Keywords
> > macht (dein eigenes VCS?) und willst einen String-Vergleich machen.
> 
> Wir haben diverse Scripte, die $Name: $ auswerten, falls Du das meist.

Ja, an sowas in der Richtung habe ich gedacht.

> > Vielleicht wäre es aber sinnvoller, den Identifier (für diese Datei)
> > ändern zu können, also von $ -> % ($Rev$ -> %Rev%) oder sogar in
> > mehrere Zeichen vielleicht.
> 
> mmm... Wir haben paar Millionen Zeilen Code in paar hundert Projekten in
> CVS, aber sowas hab ich noch nie vermisst.

Naja, man kann es ja meist mit Backslash-Quoting irgendwie umgehen oder
Variablen jeweils ein Teil davon zuweisen oder so.

Ich dachte da an einen direkten String-Vergleich im Sinne von

if [ $token eq '$Rev$' ] ...

und dann z. B. eine Warnung ausgeben, daß die Datei evt. gar nicht unter
Revision-Control steht, da das Keyword nicht expandiert ist. Das geht
natürlich exakt denn schief, wenn eben genau dieses Script dann irgendwo in
nem VCS rumliegt und der String expandiert wird. Das matcht dann fast
überhaupt nie.

Und hier wäre es dann auch evt. schön, wenn ich trotzdem Subversion sagen
könnte: Expandiere (in den Kommentaren am Dateianfang) mal die
entsprechenden Keywords (HeadURL, Rev sind wohl die wichtigsten).

Wäre dann praktisch, wenn es dann z. B. %Rev% ersetzen würde. (Was dann
natürlich die Arbeit oben genannter Scripts wieder erschwert, da sie jetzt
auch noch alle möglichen Identifier absuchen müßten.)

Naja, ob man das dann nun wirklich braucht oder will...? Vielleicht eher
doch nicht.

Gruß,
 Mike




Mehr Informationen über die Mailingliste linux-l