[linux-l] Re: Versionskontrollen

[Rocco Rutte]

Hi,

* Steffen Dettmer [07-01-22 20:05:19 +0100] wrote:
>* Rocco Rutte wrote on Mon, Jan 22, 2007 at 14:04 +0000:
>> * Steffen Dettmer [07-01-21 16:11:14 +0100] wrote:
>> > * Volker Grabsch wrote on Sun, Jan 21, 2007 at 12:54 +0100:

>> > > Besteht dein Feature hingegen aus meheren Changesets (mehreren
>> > > "commits"), musst du in Subversion einen Branch anlegen. Insbesondere
>> > > müssen beide Entwickler jeweils online sein, und der Branch muss
>> > > vorher explizit angelegt werden.

>> > WAS?! Stimmt das so? Wäre ja noch ein extremer CVS Vorteil (dass man
>> > branches nicht /vorher/ anlegen muss - weil man vorher vielleicht gar
>> > nicht weiss, dass man einen braucht)! Aber glaube ich erstmal nicht. So
>> > schlecht kann SVN ja nu auch nicht sein.

>> Was heisst denn "vorher"? Man kann Branches (also Kopie von xyz) zu
>> jeder Zeit natürlich anlegen und löschen. Mann muss vor der
>> Entwicklung eines Topics in einer Branch natürlich explizit die Branch
>> anlegen (wie in jedem anderen VCS auch), aber wieviel History das
>> eigentliche Repository schon hat ist dabei natürlich egal.

>Bei CVS muss man den Branch nicht *vorher* anlegen. Man kann ein
>sticky-Tag auschecken, drauf rumpatchen und dann branchen und
>einchecken. Geht einfach so. Ist ja wichtig, weil man ja vorher gar
>nicht immer weiss.

Ich habe das nie benutzt und brauche es nicht (ich committe immer in 
Branches und bastele die Commits so zu patches zusammen, dass sie 
bereinigt in die Zielbranch kommen), aber 'svn copy' kann auch eine 
Revision.

Also könnte man lustig patchen, dann mit der letzten eingecheckten 
Version ein Copy machen, das Ergebnis von 'svn diff' in patch(1) 
schieben, das Ergebnis des Copy committed und den Rest rückgängig 
machen. Das wird natürlich beim Umbennen, Löschen und Hinzufügen von 
Files beliebig kompliziert und aufwendig per Hand.

Aber prinzipiell sollte es gehen.

>> > Ich finde eher, die Branches in Form von Kopien sind technisch eine
>> > Kette, aber logisch gar keine Kopien (sondern Branches) und sehr wohl
>> > gerichtete Graphen. Da hat bloss jemand ein Implementierungsdetail als
>> > Feature verkauft.

>> Von der menschlichen Logik sind Branches immer Graphen, aber für 
>> Subversion eben nicht. Es gibt da nur Pfade und Revisionsnummern. Dass 
>> du jetzt branches/xyz als eine Branch und trunk/ als Hauptlinie 
>> interpretierst, interessiert subversion nicht. Es gibt nur eine lineare 
>> Liste von Änderungen an Pfaden, die mit einander etwas zu tun haben 
>> können aber nicht müssen.

>Also weiss ein Branch nicht, wo er herkommt? Wenn ich aus Versehen copy
>"a/b branche/mybranch/a/c" mache, und b und c evtl. noch ähnlich sind,
>hab ich einfach mal verloren oder wie? Wie kann ein SVN admin Fehler von
>Usern dann erkennen und korrigieren?

Ich verstehe das Beispiel nicht so richtig. Es gibt in Subversion soweit 
ich weiss und erlebt habe, keine Repository-weiten Link zwischen a/b und 
branch/mybranch/a/c nach dem Kopieren (sonst hätte schon lange jemand 
ein automatisches Merge darauf implementiert). Der einzige Link, den du 
u.a. für Merges brauchst, musst du durch viel Disziplin und 
Commit-Messages (und damit svn log) erarbeiten.

Deswegen habe ich subversion und Branches einfach aufgegeben, weil die 
ganzen Details, die bei 'svn copy' und 'svn merge' eh klar sind (die 
Revisionsnummern) ich mir hätte merken müssen und zum Beispiel auch, 
welche Revision ich schon gemerget habe und welche nicht, etc...

   bye, Rocco
-- 
:wq!