[SVN] Commit wijzigingen van vriend zonder working copy.

[Verwijderd]

Ik heb het volgende scenario. Ik maak samen met een vriend een website. Hij doet vooral HTML, layout en vormgeving en ik doe de scripting in PHP. Omdat ik bij wil houden wat hij en ik veranderen, heb ik zelf nu een SubVersion repository gemaakt. Ik check alles uit in een working copy (tevens de root van mijn test webserver) en kan zo mijn ding doen.

Nu die vriend van mij. Ik heb hier zijn 'htdocs' folder. Die is ondertussen flink anders dan mijn working copy (logisch natuurlijk). Hij heeft wijzigingen in code gemaakt, nieuwe bestanden toegevoegd, afbeeldingen vervangen en waarschijnlijk ook bestanden verwijderd. Maar het is géén working copy. Hij heeft te weinig ervaring (is helemaal geen 'coder'), dus laat ik hem gewoon in Dreamweaver z'n ding doen met de folder die ik een tijdje geleden uit de repos exporteerde.

Maar nu wil ik natuurlijk zijn wijzigingen in de repos hebben. Ik vraag mij alleen af, hoe? M.i. zijn er meerdere wegen naar Rome:

1. Zijn werk over mijn working copy heen kopieren, en dan een commit. Dan ben ik in eerste instantie mijn wijzigingen kwijt. Lijkt me niet de juiste manier, of kan dat wel?
2. Tijdelijke working copy maken (checkout), dan overschrijven met zijn werk, en commit doen. Dan heb ik alleen niet de verwijderde bestanden te pakken.
3. Zelfde als boven, maar eerst de working copy leeggooien, en dan zijn werk erin kopieren en dan een commit. Ik heb het gevoel dat dat geen goed idee is?
4. Een branch maken voor zijn werk. Maar daar heb ik bij het aanmaken van de repos geen rekeing mee gehouden, dus dan moet ik eerst de repos ombouwen met een trunk met mijn werk en een branch voor zijn werk. Maar is dit wellicht toch de beste manier?

Natuurlijk mag je zeggen, zoek het maar uit, je merkt vanzelf wel wat werkt, maar ik ben bang dat ik werk kwijtraak, en misschien kan iemand mij behoeden voor al te veel tijdverlies.

Edit
PS: Ik gebruik zelf Windows met TurtoiseSVN en Zend Studio 5

[ Voor 4% gewijzigd door Verwijderd op 14-12-2005 21:07 ]

[ShadowLord]

Het probleem met al je methodes is dat zijn werk als 'nieuw' gezien gaat worden. je gaat namlijk de laatste revisie overschrijven met zijn code, waarmee Subversion denkt: oh deze code is allemaal verandert, dus dat wordt de nieuwste revisie. Hij zal dus niets mergen.

Wat je moet doen om dit te fixen:
Zoek uit welke revisie de code was toen je hem zijn lokale kopie gaf. Maak van die versie een branch aan. Dit kan heel simpel in TortoiseSVN (Branch, en dan niet de HEAD revisie, maar de revisie die je net gevonden hebt). Mocht je repos dit niet kunnen omdat je in de root aan het werken bent zonder trunk dir etc (foei! ), dan zul je eerst even wat dir moves moeten gaan doen zodat dit wel in je repository zit. NIET JE REPOSITORY OPNIEUW MAKEN! Dan verlies je je versieinfo en de kans om zijn changes te mergen. Gewoon nieuwe dir(s) aanmaken en adden aan de repos. Dan kun je met de rechtermuis slepen en SVN Move kiezen uit het context menu.

Zodra je de oude versie gebranched hebt maak je een tijdelijke working copy aan. Die overschrijf je met zijn bestanden. Dit zooitje commit je dan weer terug in de branch. Daarna merge je de branch met de trunk en heb je een volledige versie. Het is allemaal een beetje tricky, maar wel goed te doen.

Overigens weet ik niet hoe makkelijk/moeilijk het is om te mergen nadat je file moves hebt gedaan. Intern delete SVN de files namelijk en maakt ze weer aan. Anders zul je toch met de hand moeten mergen (dus zelf de files editen).

[Verwijderd]

ShadowLord schreef op woensdag 14 december 2005 @ 23:07:
Zodra je de oude versie gebranched hebt maak je een tijdelijke working copy aan. Die overschrijf je met zijn bestanden. Dit zooitje commit je dan weer terug in de branch.

Hoe gaat dat dan werken met bestanden die hij verwijderd heeft? Dat wordt dan toch handwerk volgens mij...

[Mac_Cain13]

Als je zelf ook wijzigingen hebt gemaakt (in die mappen) zul je het op een manier doen zoals ShadowLord aangeeft. Dat is wel ff opletten en ik zelf vind mergen en dergelijke niet de meest prettige operatie.

Als je zelf geen code in die map hebt gewijzigt is de makkelijkste manier volgens mij om een tijdelijke working copy te maken. Alle mappen die van toepassing zijn een voor een leeg gooien (Niet tegelijk hele mappen deleten, want er staan verborgen .svn mappen in met info.)
Als je dat gedaan hebt map voor map zijn files in de map zetten. Zo heb je al zijn wijzigingen in de working copy zitten inclusief (niet al te nette) deletes en kun je een commit doen.
Tijdens de commit kun je TortoiseSVN zeggen dat de verdwenen files verwijderd mogen worden en ben je klaar.

Met deze methode is het wel hopen dat er niet teveel mappen zijn, want dan is het wel aardig wat werk. Overgens werkt dit ook wel als je zelf wel wijzigingen hebt gemaakt, maar nog niet gecommit. Dan moet je alleen zelf nog even wat conflicts oplossen zodra je je eigen copy gaat commiten.

Toch lijkt mij het eenvoudigst om hem in de toekomst wel in een working copy te laten werken. Je kunt hem die dan laten zippen en mailen of iets dergelijks. Dan kun jij de boel commiten, eventuele conflicts oplossen en updaten. Als dat dan klaar is kan hij een nieuwe checkout maken of je mailt het mapje terug en dan hoef jij niet met de hand alles af te werken.

[ Voor 5% gewijzigd door Mac_Cain13 op 14-12-2005 23:58 ]

[Verwijderd]

Mac_Cain13 schreef op woensdag 14 december 2005 @ 23:56:
Met deze methode is het wel hopen dat er niet teveel mappen zijn, want dan is het wel aardig wat werk

Ja, daar kan ik wel even een scriptje voor schrijven. Ik heb er nu ook een die recursief juist alleen de .svn mappen weghaalt of hernoemt. Dus dat is zo gepiept.

Toch lijkt mij het eenvoudigst om hem in de toekomst wel in een working copy te laten werken. Je kunt hem die dan laten zippen en mailen of iets dergelijks. Dan kun jij de boel commiten, eventuele conflicts oplossen en updaten. Als dat dan klaar is kan hij een nieuwe checkout maken of je mailt het mapje terug en dan hoef jij niet met de hand alles af te werken.

Ja dat zou ik ook heel graag willen. Versiebeheer is in dit geval een 'probleem' omdat hij daar helemaal niet mee bekend is (niet met het programma, maar belangrijker, ook niet met het concept). Ik hoop dat het goed gaat, de .svn folders zijn natuurlijk verborgen voor hem, maar als hij een hele folder wegggooit met daarin een .svn folder, dan heb ik wel weer een probleempje.

Ik publiceer de repos nu via Apache en mod_dav, dus ik overweeg ook om hem met Dreamweaver zijn eigen branch vanaf nu uit te laten checken via WebDAV. Dan hoef ik alleen te zeggen dat ie ff moet inchecken vanuit Dreamweaver, en dan kan ik mergen.

Misschien toch tijd voor een stoomcursus versiebeheer voor hem .

[Soultaker]

ShadowLord's suggestie klinkt heel goed, maar het is de vraag of je de originele document set wel in je repository hebt zitten (dat is me niet helemaal duidelijk). Hoe je het ook doet, het gaat in ieder geval een heleboel handwerk opleveren. Zorg sowieso voor een back-up van jouw versie en zijn versie van de code voor je er aan begint.

De makkelijkste manier om met een source code repository te werken is als alle partijen er aan meewerken en er een beetje verstand van hebben. Het lijkt me dus zeker nuttig om je collega de basisprincipes uit te leggen. Dingen als tags en branches hoeft 'ie waarschijnlijk niet te weten; het is niet zo lastig om 'm uit te leggen dat 'ie vóór 'ie gaat werken z'n lokale kopie moet updaten en naderhand - of tussendoor - z'n werk moet committen. Met die minimale kennis kun je al heel fatsoenlijk met een repository werken, met alle voordelen van dien.

[Verwijderd]

Soultaker schreef op donderdag 15 december 2005 @ 16:08:Hoe je het ook doet, het gaat in ieder geval een heleboel handwerk opleveren.

Dankzij het programma WinMerge was het nu een fluitje van een cent om zijn wijzigingen door te voeren in mijn working copy, maar het zijn ook maar 100 bestanden en er waren slechts 15-20 wijzigingen, meeste konden gelijk doorgevoerd worden. Maar toch maakte WinMerge het erg makkelijk en overzichtelijk.