2 way merge is niet identiek

[soepah]

Bij ons bedrijf maken wij gebruik van Subversion in combinatie met Trac en Tortoise. Elke week mergen wij de branch in de trunk en maken hiervan een versie.
We mergen echter nadien ook de Trunk terug in de Branch (om gelijke versies te hebben om vanaf daar weer een week te werken aan de code).
Nu valt mij op dat na zo'n merge de uitkomst niet gelijk is (maw de trunk en de branch zouden 100% identiek moeten zijn, maar zijn dit bij lange na niet).
Nu heb ik twee vragen:
1. Hoe kan het dat na deze 2-way merge deze versies niet identiek zijn?
2. Hoe kan ik voorkomen dat deze niet identiek zijn (Of hoe kan ik het oplossen zodat ze wel gelijk zijn?)

We mergen trouwens 2 kanten in omdat er een groep op de branch werkt in het buitenland, en wij hier in NL op de trunk, hiervoor is het noodzakelijk dat beiden blijven bestaan.

[MSalters]

Wat doe je precies? Merge je alle diffs gemaakt op de branch in de trunk? Dan heeft de branch natuurlijk nog niet de diffs gemaakt op de trunk.

PS. Strikt genomen is de trunk ook een branch.

[Jaap-Jan]

Hij merged de branch in de trunk en de resulterende trunk terug in de branch.

Het gebruik van de term '2-way merge' is wat misleidend, want het betekent al wat anders dan de betekenis die soepah eraan geeft.

[soepah]

MSalters schreef op maandag 17 mei 2010 @ 09:37:
Wat doe je precies? Merge je alle diffs gemaakt op de branch in de trunk? Dan heeft de branch natuurlijk nog niet de diffs gemaakt op de trunk.
PS. Strikt genomen is de trunk ook een branch.

Ik snap dat de trunk ook een branch is, dat maakt niet zoveel uit denk ik in dit verhaal.
Wat ik doe is als volgt:

1. Merge de complete software van de Trunk met de branch (Via Tortoise, inclusief historie) (Branch IN trunk mergen)
2. Tortoise merged elke file die verschillend is tussen de branch en de trunk en neemt hier (volgens de merge tool natuurlijk) de beste uitkomst van. (Laatste versie / wijziging van de files).
3. Hij slaat dit resultaat op als de huidige file en dit kan worden gebruikt.
4. Het zelfde riedeltje wordt herhaalt alleen nu de Branch mergen met de Trunk (Trunk IN branch mergen)

en de uitkomst is verschillen.

Jaap-Jan schreef op maandag 17 mei 2010 @ 10:11:
Hij merged de branch in de trunk en de resulterende trunk terug in de branch.
Het gebruik van de term '2-way merge' is wat misleidend, want het betekent al wat anders dan de betekenis die soepah eraan geeft.

Ik dacht dat het een two way merge betrof, als het een andere naam heeft dan sorry voor mijn term

[.oisyn]

Wikipedia: Merge (revision control) - Two-way merge. Oftewel, een merge van twee files die geen (bekende) common base hebben.

[ Voor 27% gewijzigd door .oisyn op 17-05-2010 11:10 ]

[YopY]

Wat zijn de verschillen dan? Doe je het mergen enzo wel goed?

Overigens kun je ook gewoon gaan mergen, de branch afsluiten / verwijderen, en opnieuw gaan branchen - dan heb je zeker een exacte kopie van je trunk, en zit je niet nog conflicten op te lossen en dergelijke.

Een 'normale' werkwijze is om tussentijds aanpassingen in de trunk door te mergen naar de branch (zodat je branch altijd de meest recente trunk + aanpassingen is) en, als de branch klaar is, deze te mergen met de trunk (en de branch 'af te sluiten').

Evt. andere aanpassingen zijn dan weer een nieuwe branch, aangezien de vorige branch nu weer geïntegreerd is met de trunk.

ASCII art:

code:

'Normale' manier van werken:

Trunk
 |
 |  branchen
 |\
 | \
 |  |
 |\ |  tussentijdse aanpassingen in trunk toepassen op branch
 | \|
 |  |
 |  |  branch mergen met trunk
 | /
 |/
 |  einde branch, nieuwe aanpassingen = nieuwe branch.
 |\
 | \
 |  |
 | /
 |/
 |
etc

Nu ik toch bezig bent, jij probeert het volgende te doen?

code:

Trunk
 |
 |  branch
 |\
 | \
 |  | 'two-way merge'
 | /|
 |/ |
 |\ |
 | \|
 |  |
 |  |
etc

[ Voor 62% gewijzigd door YopY op 17-05-2010 12:57 ]

[soepah]

YopY schreef op maandag 17 mei 2010 @ 12:51:
Wat zijn de verschillen dan? Doe je het mergen enzo wel goed?

Overigens kun je ook gewoon gaan mergen, de branch afsluiten / verwijderen, en opnieuw gaan branchen - dan heb je zeker een exacte kopie van je trunk, en zit je niet nog conflicten op te lossen en dergelijke.

Een 'normale' werkwijze is om tussentijds aanpassingen in de trunk door te mergen naar de branch (zodat je branch altijd de meest recente trunk + aanpassingen is) en, als de branch klaar is, deze te mergen met de trunk (en de branch 'af te sluiten').

Evt. andere aanpassingen zijn dan weer een nieuwe branch, aangezien de vorige branch nu weer geïntegreerd is met de trunk.

ASCII art:
...
Nu ik toch bezig bent, jij probeert het volgende te doen?

code:

Trunk
 |
 |  branch
 |\
 | \
 |  | 'two-way merge'
 | /|
 |/ |
 |\ |
 | \|
 |  |
 |  |
etc

Ik weet dat het normaal is om elke keer de branch af te sluiten, hiermee voorkom je ook verschillen.
De verschillen die ik bv tegen kom.
Revisie Beiden - 1. UINT32 a = 0;
Revisie Trunk - 2: UINT32 a = 9;
Revisie Branch - 2: UINT32 a = 8;
Na Merge:
UINT32 a = 9;
UINT32 a = 8;
(Dus 2 x declaratie, waar de compiler dus wel op waarschuwd).
Dit zijn de fouten die ik tegen kom..
En ff ascii art van hoe het gaat:

code:

Trunk
 |
 |  branch
 |\
 | \
 |  | Merge Branch -> Trunk
 | /|
 |/ |
 |\ | Merge Trunk -> Branch
 | \|
 |  | Tag
 | /| Merge Branch -> Trunk
 |/ |
 |\ | Merge Trunk -> Branch
 | \|
 |  | Tag
etc

[.oisyn]

Rare merge. Als in beide branches een verandering wordt gemaakt en die merge je weer bij elkaar, dan is er een conflict. Als je merge tool dat niet meldt en gewoon doodleuk beide changes meeneemt en achter elkaar zet dan moet je een andere merge tool gebruiken. Het is namelijk logisch dat dit conflict met mensenhanden moet worden opgelost ipv automatisch.

[ Voor 10% gewijzigd door .oisyn op 17-05-2010 13:12 ]

[frickY]

Ik zelf merge mijn Branches en Trunk meestal heen en weer via de command line "svn merge --reintegrate"
Hiermee kijkt SVN zelf in de mergeinfo welke revisies nog niet gemerged zijn, en diffed die in plaats van de gehele repository.

Ik heb geen idee hoe Tortoise bepaald welke revisies gemerged moeten worden. Maar alleen al het feit dat je in beide repositories eenmaal de regel "UINT32 a = ?" hebt, en in je uiteindelijke merge die regel dubbel is, zegt dat er iets niet goed gaat.