Problem mit svn mergen

[PatkIllA]

Wir haben immer mal wieder das Problem (ca 1-2 mal die Woche), dass beim Mergen von Änderungen bereits gemergte Revision nicht mehr als gemerged markiert sind. Die fehlen dann in der svn:mergeinfo property
Die eigentlichen Änderungen in den Dateien bleiben erhalten.

Wir nutzen einen SVN Server (1.7.x) und TortoiseSVN auf den Clients.
Gibt es da einen Bug oder eine potentielle Fehlbedienung die zu sowas führt?

[TongPo]

sowas kann z.B. passieren, wenn branches mit falschen mergeinfos falsch reintegriert werden. von svn clients halte ich wenig, kommandozeile ist da deutlich aussagekräftiger.

ich würde an deiner stelle das log durchschauen, wann genau die mergeinfo verschwunden ist.

[PatkIllA]

Das waren alles Änderungen von unserem QS branch in den trunk.
Die Revisionen habe ich schon per Script ausfinding gemacht, aber ich kann da nichts Auffälliges oder Gemeinsames finden.

[TongPo]

vor dem reintegrieren eines branches in den trunk muss sauber der trunk in den branch gemerged werden. das ist das letzte mal, wo konflike auftreten können. der commit in den trunk muss reibungslos laufen und es dürfen dabei keine mergeinfos im trunk geändert/gelöscht werden bis auf die neuen checkins aus dem branch.

an deiner stelle würde ich den commit auf dem trunk rückgängig machen, einen neuen sauberen branch erstellen und dort die änderungen nochmal einspielen (einfach per patch file, das man aus dem falschen commit erstellen kann). dann kannst du den branch sauber in den trunk reintegrieren.


ein häufiges problem sind auch subtree merges, die sollte man unbedingt vermeiden. und immer branches sauber vom trunk erstellen und wieder reintegrieren - schweinereien wie merges zwischen verschiedenen branches oder manuelles konflikte lösen bringen im endeffekt nur probleme.

[PatkIllA]

Das waren ganz normale Merges von einen branch in den anderen. Das machen wir bestimmt hundert mal im Monat ohne das es Probleme gibt.
Der QS branch wird auch nicht reintriegert. Da kommen nur Bugfixes rein.
Falls Features nicht auf die nächste Version warten können gibt es einen Branch vom QS branch. Der Featurebranch wird dann wieder in den QS Branch reintegriert. Alles was im QS branch passiert wird dann in den trunk gemerged.

Subtree-Merge sollte es eigentlich nicht geben und ein branch wird immer dahin reintegriert wo er herkommt.

[TongPo]

was genau soll der QS branch darstellen? hört sich für mich wie der eigentliche trunk an.

[PatkIllA]

Das ist der branch wo wir die Auslieferungen rauserstellen.
QS wie qualitätsgesichert.

[TongPo]

ah, ok

da ist dann der fehler. der QS sollte für jedes neue release frisch vom trunk gebrancht werden. bugfixes müssen auch auf dem trunk gemacht werden und dann sauber in den QS gemerged werden. feature branches werden auch vom trunk erstellt und dort reintegriert - und können maximal danach in den QS übernommen werden.

das ist die branch convention in eigentlich allen software buden, in denen ich bisher gearbeitet habe. sie ist relativ einfach und funktioniert.

genau solche merges zwischen branches und das verzichten auf streaming lines führt dann zu solchen problemen mit mergeinfos, wie du sie beschrieben hast.

[PatkIllA]

der QS sollte für jedes neue release frisch vom trunk gebrancht werden.
Wird er

bugfixes müssen auch auf dem trunk gemacht werden und dann sauber in den QS gemerged werden.
feature branches werden auch vom trunk erstellt und dort reintegriert - und können maximal danach in den QS übernommen werden.Eher schlecht. Auf dem trunk ist das relativ egal wenn eine Kundenanpassung zeitweise nicht funktioniert und nach einem neuen Release muss das eh wieder als ganzes getestet werden.

genau solche merges zwischen branches und das verzichten auf streaming lines führt dann zu solchen problemen mit mergeinfos, wie du sie beschrieben hast.svn unterscheidet nicht zwischen branch und trunk. Das ist alles das gleiche und die Reihenfolgen werden ja auch eingehalten. Das hat buchstablich schon tausend mal funktioniert nur halt gelegentlich nicht. Früher hatten wir das auch nicht. Allerdings waren es früher auch nur eine Handvoll Entwickler und heute 20+.

[Monger]

Jetzt wo ich das hier so lese: ja, ich hab das auch schonmal gesehen. Das war mit ein Grund, weshalb wir von 1.6 auf 1.7 umgestiegen sind (sowohl client- als auch serverseitig), weil wir unter 1.6 noch einige komische Artefakte beim mergen hatten.
Zu unserer Überraschung ist bei manchen Leuten das super gelaufen, und bei einigen immer noch komisch... aber offenbar immer dann wenn das Working Directory nur upgegradet statt frisch ausgecheckt wurde.

Das Mergeinfo Property ist ja ein Stück weit "nur" für die saubere History wichtig, ist ja zum Glück für die Datenkonsistenz zweitrangig. Aber ja, ich glaube das ist ein Bug des SVN Clients.

[PatkIllA]

Hoer mal mein Script zum feststellen. Der aktuelle Ordner muss ein Working copy sein und als Parameter gibt man die von bis Revisionen an.
@echo off
SETLOCAL ENABLEDELAYEDEXPANSION
if [%2]==[] (
for /F "tokens=1,2" %%i in ('svn info') do if %%i==Revision: SET END=%%j
if [%1]==[] (
SET /A START=!END!-200
) ELSE (
SET /A START=!END!-%1
)
) ELSE (
SET START=%1
SET END=%2
)

for /L %%i in (!START!,1,!END!) do (
set /A prev=%%i-1
svn diff -x -u --depth empty -r !prev!:%%i | findstr "Reverse-merged"
if !ERRORLEVEL!==0 (
svn info -r %%i | findstr "Revision: Author: Date:"
echo.
)
)

[TongPo]

Das Mergeinfo Property ist ja ein Stück weit "nur" für die saubere History wichtig, ist ja zum Glück für die Datenkonsistenz zweitrangig. Aber ja, ich glaube das ist ein Bug des SVN Clients.

oha! da dreht sich bei mir alles im magen um, wenn ich das lese ;)
branchen ohne diese kleine property funktioniert in SVN nicht. ohne bekommst du einfach mal so z.B. code dopplungen.

2PatkIllA:
wenn du die revisionen schon hast, die die mergeinfos kaputt gemacht haben, dann kannst du ja auch weiter gehen und genau schauen, wo und wie es dazu kam. ich kann nur aus erfahrung sagen, das die begriffe "trunk" und "branch" in bezug auf SVN nicht zufällig so heissen. ein svn repository spannt einen baum auf - und bäume sind per definition kreisfrei. wenn zwischen verschiedenen branches wild hin- und hergemerged wird, dann kommen aber genau diese kreise rein, aus denen am ende inkonsitenzen resultieren. es funktioniert dann tausend mal, aber gelegentlich dann ebend auch nicht...

[PatkIllA]

oha! da dreht sich bei mir alles im magen um, wenn ich das lese ;)
branchen ohne diese kleine property funktioniert in SVN nicht. ohne bekommst du einfach mal so z.B. code dopplungen.In den ersten Subversion versionen ging das ja auch ohne und man musste sich halt irgendwie merken was man schon gemerged hatte um keine Doppelungen zu haben.

2PatkIllA:
wenn du die revisionen schon hast, die die mergeinfos kaputt gemacht haben, dann kannst du ja auch weiter gehen und genau schauen, wo und wie es dazu kam. ich kann nur aus erfahrung sagen, das die begriffe "trunk" und "branch" in bezug auf SVN nicht zufällig so heissen. ein svn repository spannt einen baum auf - und bäume sind per definition kreisfrei. wenn zwischen verschiedenen branches wild hin- und hergemerged wird, dann kommen aber genau diese kreise rein, aus denen am ende inkonsitenzen resultieren. es funktioniert dann tausend mal, aber gelegentlich dann ebend auch nicht...Wir haben ja nur in eine Richtung gemerged.

[TongPo]

In den ersten Subversion versionen ging das ja auch ohne und man musste sich halt irgendwie merken was man schon gemerged hatte um keine Doppelungen zu haben.
also ich will mir keine revisionen merken müssen :biggrin: - das wird auch ein wenig unübersichtlich, wenn es in den 5 oder 6 stelligen bereich geht.

Wir haben ja nur in eine Richtung gemerged.
ok, dann ist ja gut. bleibt wohl wirklich nur reverse engineering durch die history. vielleicht habt ihr ja einen entwickler, der falsch merged oder gerne mal mit patches arbeitet.

ohne direkten zugriff auf euer SVN kann hier im thread dann aber nur vermutet werden. ;(

[PatkIllA]

also ich will mir keine revisionen merken müssen :biggrin: - das wird auch ein wenig unübersichtlich, wenn es in den 5 oder 6 stelligen bereich geht.
Das ist zum Glück ja seit längerem nicht mehr nötig.
ok, dann ist ja gut. bleibt wohl wirklich nur reverse engineering durch die history. vielleicht habt ihr ja einen entwickler, der falsch merged oder gerne mal mit patches arbeitet.
In den letzten 1500 Revisionen ist das 4 mal bei 4 verschiedenen Entwicklern passiert
ohne direkten zugriff auf euer SVN kann hier im thread dann aber nur vermutet werden. ;(Das geht wohl eher nicht. Wonach könnte man denn noch gucken?

[TongPo]

ein grosses manko was SVN hat, ist "svn move". das funktioniert über branchgrenzen hinweg nicht ordentlich. in wirklichkeit wird dabei nämlich ein delete und ein add der alten version gemacht. wenn man z.B. ein move vom trunk in seinen branch reinholt, verliert man alle änderungen, die man an den betroffenen dateien gemacht hat und es wird einfach die entsprechende version aus dem trunk geholt.

sonst ist gibt es nicht viel, wonach man noch schauen kann. vielleicht ist der umstieg auf ein verteiltes VCS eine lösung für euch. git z.B. arbeitet komplett anders mit branches und merges - die umstellung darauf kann in einem kleinen team sehr gut funktionieren. allerdings muss man dabei auch schulungsaufwand einplanen und eigentlich auch die arbeitsprozesse anpassen.

[PatkIllA]

Das ein move nicht ordentlich funktioniert haben wir auch schon öfters erfahren müssen.
Mich persönlich würde Git zwar reizen, aber ich glaube vom Workflow her bringt uns das wenig und Umstellung von Prozessen und Mitarbeitern wäre zu teuer.

[Monger]

oha! da dreht sich bei mir alles im magen um, wenn ich das lese ;)
branchen ohne diese kleine property funktioniert in SVN nicht. ohne bekommst du einfach mal so z.B. code dopplungen.

Nein, das stimmt nicht. Es wird ja grundsätzlich lokal gemergt, ergo existiert kein funktionaler Unterschied ob du die Änderungen tatsächlich lokal von Hand gemacht hast, oder per Tool. Technisch gesehen ist das nix anderes als wenn du alle Revisionen von Branch A als Patch speichern und auf Branch B anwenden würdest. Also quasi was du zuerst vorgeschlagen hast, nur dass Patches halt grundsätzlich nie Metainfos mitschleppen. Woher auch, sie stammen ja aus keiner bestimmten Revision.

Die Merge Property wird nur vom Log ausgewertet, damit klar wird: aha, da und da hat es einen Merge gegeben. Mehr steht da ja auch nicht drin, kannst dir ja selber das Property anschauen. Da steht nicht mehr als der Pfad und die Revisionsnummer. Die könntest du auch von Hand eintragen, würde fürs Mergen keinen Unterschied machen.

[TongPo]

2 Monger:

teilweise alles richtig - aber du hast nicht verstanden, wofür diese mergeinfos sind. normalerweise arbeitet man in einen branch, macht ein paar commits, macht einen update merge from trunk, wieder ein paar commits und so weiter. bis dahin alles kein problem ohne mergeinfos. wenn man diesen branch allerdings wieder reintegrieren will, muss SVN wissen, welche commits aus dem branch änderungen vom developer sind und welche einfach nur update merges vom trunk. und da hast du ohne diese kleine property verloren.

mit mergeinfos ist es auch nicht möglich ein changeset öfter als einmal zu mergen. das war auch das problem vor SVN 1.5 - da hat svn merge einfach wie ein besseres patch gearbeitet.

ich nutze manchmal auch patch files um änderungen in einen andern branch zu bekommen. das ist auch kein problem, wenn man danach sauber die mergeinfo nachzieht - dafür gibts einen schalter im merge kommando von svn. man muss halt nur wissen, was man macht und warum man es macht.

[Monger]

2 Monger:

teilweise alles richtig - aber du hast nicht verstanden, wofür diese mergeinfos sind. normalerweise arbeitet man in einen branch, macht ein paar commits, macht einen update merge from trunk, wieder ein paar commits und so weiter. bis dahin alles kein problem ohne mergeinfos. wenn man diesen branch allerdings wieder reintegrieren will, muss SVN wissen, welche commits aus dem branch änderungen vom developer sind und welche einfach nur update merges vom trunk. und da hast du ohne diese kleine property verloren.

Ich bin kein Branchmaster, deshalb hab ich da zugegebenermaßen nicht so viel Erfahrung, aber ich versteh das Problem nicht. Wenn ich eine bereits gepatchte Datei erneut patche, passiert doch schlicht gar nichts. Ergo: Änderungen die vom Trunk in den Branch gewandert sind, dürften doch bei der Reintegration in den Trunk schlicht gar nichts ändern.

Hmm... es sei denn in der Datei ändert sich zwischendrin noch irgendwas. Weil im Patch File stehen ja die Zeilennummern dran. Wenn die verrutschen, gibt es ohne weitere Metainfos möglicherweise Tohuwabohu.

[TongPo]

Wenn ich eine bereits gepatchte Datei erneut patche, passiert doch schlicht gar nichts. Ergo: Änderungen die vom Trunk in den Branch gewandert sind, dürften doch bei der Reintegration in den Trunk schlicht gar nichts ändern.

doch klar. ein patch file kann man unendlich oft auf eine datei anwenden. im besten fall bekommst du ein "hunk" oder im SVN kontext einen konflikt. im schlimmsten fall läuft alles sauber durch.

beim reintegrieren werden alle revisionen des branches genommen und daraus ein grosses changeset erstellt, was dann auf den trunk angewendet wird. und ohne mergeinfos sind dann auch die update merges drin.

VC systeme sind eigentlich total ungeeignet, um code zu versionieren, da sie ihn garnicht verstehen. sie sind wie ein blinder als chauffeur.