Fletting av forandringer høres enkelt ut, men i praksis kan det bli en hodepine. Problemet er at hvis du gjentatte ganger fletter forandringer fra en gren til en annen, kan du ved en ulykke flette den samme forandringen to ganger. Når dette skjer, vil det noen ganger gå bra. Når ei fil blir patchet vil Subversion vanligvis oppdage at fila inneholder forandringen, og gjør ingenting. Men hvis den allerede eksisterende forandringen er blitt forandret på en eller annen måte, vil du få en konflikt.

Ideelt sett bør versjonskontrollsystemet forhindre forsøket på å legge inn doble forandringer til en gren. Det bør huske automatisk hvilke forandringer en gren allerede har mottatt, og bør være i stand til å liste dem ut for deg. Det bør bruke denne informasjonen til å hjelpe til med å automatisere flettinger så mye som mulig.

Dessverre er ikke Subversion et sånt system. I likhet med CVS lagrer ikke Subversion 1.0 noen informasjon om fletteoperasjoner. Når du legger inn lokale forandringer, har ikke depotet noen idé om hvorvidt disse forandringene kom fra en kjøring av svn merge, eller fra en redigering av filene for hånd.

Hva betyr dette for deg, brukeren? Det betyr at inntil den dagen Subversion får denne funksjonen, må du selv holde rede på fletteinformasjonen. Den beste plassen å gjøre dette er i selve loggmeldingen. Som demonstrert i det tidligere eksempelet, anbefales det at loggmeldingen din nevner et spesifikt revisjonsnummer (eller område av revisjoner) som blir flettet inn i grenen. Senere kan du kjøre svn log for å se over hvilke forandringer forgreningen allerede inneholder. Dette vil la deg varsomt konstruere en etterfølgende svn merge-kommando som ikke vil bli overflødig i forhold til tidligere flettede forandringer.

I den neste seksjonen vil vi vise noen eksempler på denne teknikken i praksis.

Fordi fletting bare resulterer i lokale modifikasjoner, er det vanligvis ikke noen høyrisikooperasjon. Hvis flettingen går galt første gangen, kan du kjøre svn revert på forandringene og prøve igjen.

Men det er derimot mulig at arbeidskopien din allerede inneholder lokale forandringer. Forandringene lagt inn av en fletting vil bli blandet med de du har fra før, og det å kjøre svn revert er ikke lenger et alternativ. De to settene med forandringer kan bli umulig å separere.

I tilfeller som dette vil det være greit å kunne forutsi eller undersøke forandringer før de skjer. En enkel måte å gjøre det på er å kjøre svn diff med de samme argumentene som du planlegger å gi til svn merge, som vi allerede har vist i det første eksemplet vårt med fletting. En annen metode for forhåndsvisning er å angi --dry-run-valget til flettekommandoen:

$ svn merge --dry-run -r 343:344 http://svn.example.com/repos/calc/trunk
U  integer.c

$ svn status
# ingenting blir skrevet ut, arbeidskopien er fortsatt uforandret.

--dry-run-valget gjør egentlig ingen forandringer i arbeidskopien. Det viser bare statuskoder som ville blitt skrevet ut under en virkelig fletting. Det er nyttig for å få en “høynivå”-oversikt over den potensielle flettingen for de gangene der kjøring av svn diff gir alt for mange detaljer.

Akkurat som svn update-kommandoen, legger svn merge inn forandringer i arbeidskopien din. Og derfor er den også i stand til å lage konflikter. Konfliktene produsert av svn merge er imidlertid noen ganger forskjellige, og denne seksjonen forklarer disse forskjellene.

Til å begynne med, tenk deg at arbeidskopien din ikke inneholder noen lokale redigeringer. Når du svn update-er til en spesiell revisjon, vil forandringene sendt fra serveren alltid bli lagt inn på en “renslig” måte i arbeidskopien. Serveren produsererer deltaet ved å sammenligne to trær: Et virtuelt øyeblikksbilde av arbeidskopien din, og revisjonstreet du er er interessert i. Fordi den venstre siden av sammenligningen er nøyaktig lik det du allerede har, er deltaet garantert å korrekt konvertere arbeidskopien din til treet som er på høyre side.

Men svn merge har ingen slike garantier og kan være mye mer kaotisk: Brukeren kan be serveren om å sammenligne alle mulige trær, til og med trær som ikke er relatert til arbeidskopien! Dette betyr at det er et stort potensiale for menneskelige feil. Brukere vil noen ganger sammenligne to gale trær, og dermed lage et delta som ikke kan legges inn på en ren måte. svn merge vil gjøre sitt beste for å legge inn så mye av deltaet som mulig, men noen deler kan være umulige. Akkurat som patch-kommandoen i Unix noen ganger klager over “failed hunks”, vil svn merge klage over “skipped targets”:

$ svn merge -r 1288:1351 http://svn.example.com/repos/branch
U  foo.c
U  bar.c
Hoppet over savnet mål: «baz.c»
U  glub.c
C  glorb.h

$

I det forrige eksempelet kan tilfellet være at baz.c eksisterer både i øyeblikksbildet av grenen som sammenlignes, og det resulterende deltaet vil forandre filens innhold, men fila eksisterer ikke i arbeidskopien. Hva som enn er tilfelle, betyr “skipped”-meldingen at brukeren mest sannsynlig sammenligner to gale trær; de er det klassiske tegnet på en feil gjort av brukeren. Når dette skjer er det lett å rekursivt omgjøre alle forandringene gjort under flettingen (svn revert --recursive), slette eventuelle uversjonerte filer eller kataloger som ligger igjen etter tilbakestillingen, og kjøre svn merge med forskjellige argumenter.

Legg også merke til at det forrige eksempelet viser en konflikt som skjer i glorb.h. Vi har allerede fastslått at arbeidskopien ikke har noen lokale forandringer; hvordan er det da mulig at en lokal konflikt kan oppstå? Igjen, fordi brukeren kan bruke svn merge for å definere og legge til enhver gammel delta til arbeidskopien, kan denne deltaen inneholde tekstmessige forandringer som ikke kan legges helt uproblematisk inn i en arbeidsfil, selv om denne fila ikke har noen lokale forandringer.

En annen liten forskjell mellom svn update og svn merge er navnene på fulltekst-filene som blir opprettet når en konflikt oppstår. I “Løse konflikter (Flette inn andres forandringer)” så vi at en oppdatering produserer filene filnavn.mine, filnavn.rGAMMELREV og filnavn.rNYREV. Men når svn merge produserer en konflikt, oppretter den tre filer kalt filnavn.working, filnavn.left og filename.right. I dette tilfellet beskriver terminologien “left” og “right” hvilken side fila kom fra. I alle fall, disse forskjellige navnene vil hjelpe deg å skille mellom filer som er opprettet som følge av en oppdatering versus filer som er opprettet som resultat av en fletting.

Når du snakker med en Subversionutvikler kan det hende du hører referanser til begrepet slektskap – ancestry. Dette ordet blir brukt til å beskrive forholdet mellom to objekter i et depot: Hvis de er relaterte til hverandre, vil det ene objektet være en stamfar til det andre.

For eksempel, tenk deg at du legger inn revisjon 100, som inkluderer en forandring i ei fil kalt foo.c. Da er foo.c@99 en “stamfar” til foo.c@100. På den annen side, tenk at du legger inn en sletting av foo.c i revisjon 101, og deretter legger til en ny fil med det samme navnet i revisjon 102. I dette tilfellet kan det se ut som om foo.c@99 og foo.c@102 er relaterte (de har den samme filstien), men de er faktisk totalt forskjellige objekter i depotet. De deler ingen historie eller “slektskap”.

Grunnen til at vi tar dette opp er for å fremheve en viktig forskjell mellom svn diff og svn merge. Den første kommandoen ignorerer slektskap, mens den sistnevnte kommandoen er ganske følsom for det. Hvis du for eksempel ber svn diff om å sammenligne revisjon 99 og 102 av foo.c, vil du se linjebaserte forskjeller; diff-kommandoen sammenligner blindt to stier. Men hvis du ber svn merge om å sammenligne de samme to objektene, vil den oppdage at de er urelaterte og først prøve å slette den gamle fila og deretter legge til den nye fila. Utdataene fra programmet vil indikere en sletting etterfulgt av en tillegging:

D  foo.c
A  foo.c

De fleste flettinger involverer sammenligning av trær som er slektsmessig relatert til hverandre, og derfor har svn merge denne oppførselen som standard. Men nå og da vil du kanskje bruke merge-kommandoen til å sammenligne to urelaterte trær. For eksempel har du kanskje importert to kildekodetrær som representerer forskjellige utgivelser av et programprosjekt (se “Leverandørgrener”). Hvis du ber svn merge om å sammenligne de to trærne, vil du se at hele det første treet blir slettet, fulgt av en tillegging av hele det andre treet!

I disse situasjonene vil du at svn merge bare gjør en stibasert sammenligning og ignorerer enhver relasjon mellom filer og kataloger. Legg til valget --ignore-ancestry til flettekommandoen, og den vil oppføre seg akkurat som svn diff. (Og på motsatt måte vil --notice-ancestry-valget få svn diff til å oppføre seg som merge-kommandoen.