Manuals

Spajanje

Kadar se veje uporabljajo za ločeno razvijanje, kasneje želite spremembe na eni veji spojiti nazaj v glavno vejo oz. obratno.

It is important to understand how branching and merging works in Subversion before you start using it, as it can become quite complex. It is highly recommended that you read the chapter Branching and Merging in the Subversion book, which gives a full description and many examples of how it is used.

Naslednja stvar, ki jo je treba poudariti, je, da se spajanje vedno izvaja v delovni kopiji. Če želite spremembe spojiti v vejo, morate imeti delovno kopijo, prevzeto iz te veje, in na njej izvesti ukaz TortoiseSVNSpoji....

V splošnem je priporočljivo, da spajanje izvajate ob nespremenjeni delovni kopiji. Če ste naredili kakšne spremembe v delovni kopiji, jih najprej objavite. Če operacija spajanja ne bo uspela, boste verjetno želeli povrniti spremembe. Ukaz Povrni bo izbrisal vse spremembe na delovni kopiji, vključno s tistimi, ki ste jih naredili pred poskusom spajanja.

Poznamo tri načine spajanja, ki se med seboj nekoliko razlikujejo. Izbiro načina vam omogoča prva stran čarovnika za spajanje.

Spoji območje revizij

Ta metoda pokriva primer, ko ste na veji (ali na glavni veji) naredili spremembe, ki jih sedaj želite prenesti na drugo vejo.

What you are asking Subversion to do is this: Calculate the changes necessary to get [FROM] revision 1 of branch A [TO] revision 7 of branch A, and apply those changes to my working copy (of trunk or branch B).

If you leave the revision range empty, Subversion uses the merge-tracking features to calculate the correct revision range to use. This is known as a reintegrate or automatic merge.

Spoji dveh različni drevesi

This is a more general case of the reintegrate method. What you are asking Subversion to do is: Calculate the changes necessary to get [FROM] the head revision of the trunk [TO] the head revision of the branch, and apply those changes to my working copy (of the trunk). The net result is that trunk now looks exactly like the branch.

If your server/repository does not support merge-tracking then this is the only way to merge a branch back to trunk. Another use case occurs when you are using vendor branches and you need to merge the changes following a new vendor drop into your trunk code. For more information read the chapter on vendor branches in the Subversion Book.

Spajanje območja revizij

Slika 4.56. Čarovnik za spajanje - Izberite obseg revizije

Čarovnik za spajanje - Izberite obseg revizije


V polje Izvorni naslov URL za spajanje: vnesite poln naslov URL veje ali oznake s spremembami, ki jih želite spojiti v delovno kopijo. Lahko pa kliknete na gumb .... S tem pobrskate po skladišču in najdete željeno vejo. Če ste s te veje že spajali, lahko uporabite spustni seznam, ki prikazuje zgodovino že vnešenih naslovov URL.

If you are merging from a renamed or deleted branch then you will have to go back to a revision where that branch still existed. In this case you will also need to specify that revision as a peg revision in the range of revisions being merged (see below), otherwise the merge will fail when it can't find that path at HEAD.

V polje Območje revizij za spajanje vnesite seznam revizij, ki jih želite spojiti. Lahko vpišete eno revizijo, seznam določenih revizij, ločenih z vejicami, območje revizij, ločenih z vezajem ali kombinacijo vsega naštetega.

If you need to specify a peg revision for the merge, add the peg revision at the end of the revisions, e.g. 5-7,10@3. In the above example, the revisions 5,6,7 and 10 would be merged, with 3 being the peg revision.

Pomembno

There is an important difference in the way a revision range is specified with TortoiseSVN compared to the command line client. The easiest way to visualise it is to think of a fence with posts and fence panels.

With the command line client you specify the changes to merge using two fence post revisions which specify the before and after points.

With TortoiseSVN you specify the changeset to merge using fence panels. The reason for this becomes clear when you use the log dialog to specify revisions to merge, where each revision appears as a changeset.

If you are merging revisions in chunks, the method shown in the Subversion book will have you merge 100-200 this time and 200-300 next time. With TortoiseSVN you would merge 100-200 this time and 201-300 next time.

This difference has generated a lot of heat on the mailing lists. We acknowledge that there is a difference from the command line client, but we believe that for the majority of GUI users it is easier to understand the method we have implemented.

Najlažji način, kako izberete večje število revizij, je s klikom na gumb Pokaži dnevnik; prikazalo se bo okno s seznamom zadnjih sprememb in pripadajočimi komentarji. Če želite spojiti spremembe iz ene revizije, izberite to revizijo. Če želite spojiti spremembe iz več revizij, izberite območje (z uporabo modifikatorja Shift). Kliknite na gumb V redu in seznam številk revizij se bo samodejno izpolnil.

Če želite spremembe spojiti nazaj ven iz delovne kopije (da prekličete že objavljeno spremembo), izberite revizije, ki jih želite povrniti in potrdite polje Obratno spajanje.

If you have already merged some changes from this branch, hopefully you will have made a note of the last revision merged in the log message when you committed the change. In that case, you can use Show Log for the Working Copy to trace that log message. Remembering that we are thinking of revisions as changesets, you should Use the revision after the end point of the last merge as the start point for this merge. For example, if you have merged revisions 37 to 39 last time, then the start point for this merge should be revision 40.

Če uporabljete sledenje spajanja, vam ni potrebno vedeti, katere revizije ste že spojili - Subversion si jih zapomni. Če pustite polje za vnos območja revizij prazno, bodo samodejno vključene vse revizije, ki še niso bile spojene. Za več informacij preberite “Sledenje spajanja”.

When merge tracking is used, the log dialog will show previously merged revisions, and revisions pre-dating the common ancestor point, i.e. before the branch was copied, as greyed out. The Hide non-mergeable revisions checkbox allows you to filter out these revisions completely so you see only the revisions which can be merged.

Če v skladišču objavljajo tudi drugi uporabniki, potem bodite pri uporabi spajanja do revizije HEAD previdni. Revizija HEAD mogoče ni tista, kot mislite, saj je od vaše zadnje posodobitve delovne kopije lahko kak drug uporabnik naredil objavo.

If you leave the range of revisions empty or have the radio button all revisions checked, then Subversion merges all not-yet merged revisions. This is known as a reintegrate or automatic merge.

Za izvajanje vključevanja veje morajo biti izpolnjeni določeni pogoji. Strežnik mora podpirati sledenje spajanja. Delovna kopija mora biti prevzeta v celoti (delni prevzemi niso dovoljeni) in biti brez krajevnih sprememb, preklopov ali elementov, posodobljenih na starejše revizije. Vse spremembe, narejene na glavni veji, morajo biti že spojene na stransko vejo (oziroma morajo biti označene kot spojene). Območje revizij za spajanje se določi samodejno.

Click Next and go to “Možnosti spajanja”.

Spajanje dveh različnih dreves

Slika 4.57. Čarovnik za spajanje - Spajanje dreves

Čarovnik za spajanje - Spajanje dreves


Če ta način uporabljate za spajanje stranske veje na glavno vejo, morate čarovnika za spajanje zagnati iz delovnke kopije glavne veje.

V polje Od: vpišite poln naslov URL mape glavne veje. To se morda zdi napačno, a ne pozabite, da je glavna veja začetna točka spajanja, na katero želite dodati spremembe iz veje, kjer ste razvijali novo zmožnost. Uporabite lahko tudi gumb ... in pobrskate po skladišču.

V polje Do: vpišite poln naslov URL mape veje, kjer ste razvijali novo zmožnost.

V polji Revizija vpišite zadnji reviziji, pri kateri sta bili drevesi sihnronizirani. Če ste prepričani, da sprememb ne objavlja nihče drug, lahko v obeh primerih uporabite revizijo HEAD. Če obstaja možnost, da je po sinhronizaciji še kdo drug objavljal spremembe, potem raje uporabite točno določeno številko revizije, da se izognete izgubi sprememb iz novejših objav.

Za izbiro revizije lahko uporabite tudi gumb Pokaži dnevnik.

Možnosti spajanja

Ta stran čarovnika vam pred začetkom spajanja omogoča nastavitev naprednih možnosti. V večini primerov lahko uporabite kar privzete nastavitve.

Določite lahko globino spajanja, ki pove, kako globoko v delovno kopijo spajanje deluje. Za definicijo globine poglejte “Globina prevzema”. Privzeta globina je delovna kopija, ki uporablja obstoječo nastavitev globine, kar največkrat tudi potrebujete.

Most of the time you want merge to take account of the file's history, so that changes relative to a common ancestor are merged. Sometimes you may need to merge files which are perhaps related, but not in your repository. For example you may have imported versions 1 and 2 of a third party library into two separate directories. Although they are logically related, Subversion has no knowledge of this because it only sees the tarballs you imported. If you attempt to merge the difference between these two trees you would see a complete removal followed by a complete add. To make Subversion use only path-based differences rather than history-based differences, check the Ignore ancestry box. Read more about this topic in the Subversion book, Noticing or Ignoring Ancestry.

Določite lahko, kako se upoštevajo zaključki vrstic in presledki. Možnosti so opisane v “Nastavitev zaključkov vrstic in presledkov”. Privzeto obnašanje je, da se zaključki vrstic in presledki obravnavajo enako kot vse druge spremembe.

The checkbox marked Force the merge is used to avoid a tree conflict where an incoming delete affects a file that is either modified locally or not versioned at all. If the file is deleted then there is no way to recover it, which is why that option is not checked by default.

Če uporabljate sledenje spajanja in želite revizijo označiti kot spojeno brez dejanskega spajanja, potrdite polje Zgolj zabeleži spajanje. To lahko naredite iz dveh razlogov. Lahko se zgodi, da je spajanje prezahtevno, da bi ga prepustili programu in naredite spremembe ročno, nato pa revizijo označite kot spojeno, da sistem sledenja spajanja ve za to. Drug razlog pa je, da želite preprečiti spajanje določene revizije. Če takšno revizijo označite kot spojeno, s tem preprečite ponovno spajanje (velja le za odjemalce, ki poznajo možnost sledenja spajanja).

Now everything is set up, all you have to do is click on the Merge button. If you want to preview the results Test Merge simulates the merge operation, but does not modify the working copy at all. It shows you a list of the files that will be changed by a real merge, and notes files where conflicts may occur. Because merge tracking makes the merge process a lot more complicated, there is no guaranteed way to find out in advance whether the merge will complete without conflicts, so files marked as conflicted in a test merge may in fact merge without any problem.

The merge progress dialog shows each stage of the merge, with the revision ranges involved. This may indicate one more revision than you were expecting. For example if you asked to merge revision 123 the progress dialog will report Merging revisions 122 through 123 . To understand this you need to remember that Merge is closely related to Diff. The merge process works by generating a list of differences between two points in the repository, and applying those differences to your working copy. The progress dialog is simply showing the start and end points for the diff.

Preverjanje rezultatov spajanja

Spajanje je sedaj zaključeno. Dobra praksa je, da rezultat spajanja preverimo. Spajanje je ponavadi kar komplicirano. Če je neka veja precej različna od glavne veje, se pri spajanju pogosto pojavijo spori.

Namig

Whenever revisions are merged into a working copy, TortoiseSVN generates a log message from all the merged revisions. Those are then available from the Recent Messages button in the commit dialog.

To customize that generated message, set the corresponding project properties on your working copy. See “Merge log message templates”

Pri uporabi odjemalcev in strežnika Suversion pred različico 1.5 se informacije o spajanju ne shranjujejo in jih je zato treba voditi ločeno. Ko ste spajanje preverili in ste pripravljeni na objavo spojene revizije, v sporočilo dnevniškega zapisa vedno vpišite številke revizij, ki ste jih prenesli. Če boste kasneje spet spajali s te veje, boste morali vedeti, katere revizije ste že spojili. Sprememb ne smete spajati dvakrat. Za več informacij preberite Best Practices for Merging v knjigi The Subversion book.

Če strežnik in vsi odjemalci uporabljajo Subversion 1.5 ali novejši, zmožnost sledenje spajanja shrani spojene revizije in prepreči večkratno spajanje iste revizije. S tem si precej olajšate delo, saj lahko vedno izberete celotno območje revizij, spojene pa bodo le nove revizije.

Upravljanje vej je pomembno. Če želite biti na veji v koraku z glavno vejo, morate dovolj pogosto opravljati spajanje, da se veja in glavna veja ne oddaljita preveč ena od druge. Seveda se morate še vedno izogibati ponavljajočemu se spajanju sprememb, kot je opisano zgoraj.

Namig

V tem primeru veje za razvoj nove zmožnosti ne potrebujete več, ker ste novo kodo že integrirali na glavno vejo. Veja je sedaj odvečna in jo lahko izbrišete iz skladišča, če želite.

Pomembno

Subversion ne more spojiti datoteke z mapo in obratno - spaja lahko mape v mape in datoteke v datoteke. Če izberete datoteko in odprete okno za spajanje, potem morate v oknu navesti pot do datoteke. Če izberete mapo in odprete okno, potem morate vnesti naslov URL mape za spajanje.

Sledenje spajanja

Subversion 1.5 prinaša zmožnost sledenja spajanja. Ko spajate spremembe iz enega drevesa v drugega, se številke spojenih revizij shranijo. Te informacije se lahko nato uporabijo za različne namene.

  • Večkratnemu spajanju iste revizije se lahko izognete. Ko je revizija označena kot spojena, jo bo Subversion pri naslednjih poskusil enostavno preskočil.

  • Ko spremembe na veji spojite nazaj na glavno vejo, vam lahko dnevnik za glavno vejo prikaže tudi objave na posebni veji. S tem lažje sledite spremembam.

  • When you show the log dialog from within the merge dialog, revisions already merged are shown in grey.

  • Pri prikazu krivdnih informacij datoteke lahko prikažete avtorje spojenih revizij namesto avtorja, ki je opravil spajanje.

  • Revizije lahko označite kot ne spajaj. To storite tako, da jih dodate na seznam spojenih revizij, čeprav se spajanje dejansko nikoli ni zgodilo.

Informacije o sledenju spajanja odjemalec ob spajanju shrani v lastnost svn:mergeinfo. Ko je spajanje objavljeno, strežnik te informacije shrani v bazo podatkov, zato se ob zahtevi po spajanju, prikazu dnevnika ali krivde lahko ustrezno odzove. Da bi sistem deloval, morate nadgraditi tako strežnik kot tudi vse odjemalce. Starejši odjemalci namreč ne shranjujejo lastnosti svn:mergeinfo, starejši strežniki pa ne pošiljajo zahtevanih informacij novim odjemalcem.

Find out more about merge tracking from Subversion's Merge tracking documentation.

Handling Conflicts after Merge

Pomembno

The text in the conflict resolver dialogs are provided by the SVN library and might therefore not (yet) be translated as the TortoiseSVN dialogs are. Sorry for that.

Merging does not always go smoothly. Sometimes there is a conflict. TortoiseSVN helps you through this process by showing the merge conflict dialog.

Slika 4.58. The Merge Conflict Dialog

The Merge Conflict Dialog


It is likely that some of the changes will have merged smoothly, while other local changes conflict with changes already committed to the repository. All changes which can be merged are merged. The Merge Conflict dialog gives you different ways of handling the lines which are in conflict.

For normal conflicts that happen due to changes in the file content or its properties, the dialog shows buttons which allow you to chose which of the conflicting parts to keep or reject.

Postpone

Don't deal with the conflict now. Let the merge continue and resolve the conflicts after the merge is done.

Accept base

This leaves the file as it was, without neither the changes coming from the merge nor the changes you've made in your working copy.

Accept incoming

This discards all your local changes and uses the file as it arrives from the merge source.

Reject incoming

This discards all the changes from the merge source and leaves the file with your local edits.

Accept incoming for conflicts

This discards your local changes where they conflict with the changes from the merge source. But it leaves all your local changes which don't conflict.

Reject conflicts

This discards changes from the merge source which conflict with your local changes. But it keeps all changes that don't conflict with your local changes.

Mark as resolved

Marks the conflicts as resolved. This button is disabled until you use the button Edit to edit the conflict manually and save those changes back to the file. Once the changes are saved, the button becomes enabled.

Uredi

Starts the merge editor so you can resolve the conflicts manually. Don't forget to save the file so the button Mark as resolved becomes enabled.

If there's a tree conflict, please first see “Tree Conflicts” about the various types of tree conflicts and how and why they can happen.

To resolve tree conflicts after a merge, a dialog is shown with various options on how to resolve the conflict:

Slika 4.59. The Merge Tree Conflict Dialog

The Merge Tree Conflict Dialog


Since there are various possible tree conflict situations, the dialog will show buttons to resolve those depending on the specific conflict. The button texts and labels explain what the option to resolve the conflict does. If you're not sure, either cancel the dialog or use the Postpone button to resolve the conflict later.

Vzdrževanje stranskih vej

Pri razvijanju nove zmožnosti na stranski veji se je koristno odločiti, kako se razvoj na stranski veji vključi v glavno vejo razvoja. Če se na glavni veji (trunk) dogajajo spremembe, se lahko zgodi, da se po določenem času veji zelo razlikujeta, tako da združevanje postane prava nočna mora.

Če je zmožnost enostavna, njen razvoj pa ne bo dolgotrajen, se lahko določite, da stransko vejo povsem ločite od glavne. Ko je razvoj na stranski veji končan, spremembe spojite nazaj na glavno vejo. V čarovniku za spajanje uporabite opcijo poji območje revizij, pri čemer za območje spajanja uporabite območje revizij stranske veje.

Če bo razvoj na stranski veji potekal dalj časa, pri tem pa morate upoštevati tudi spremembe na glavni veji, morate poskrbeti, da sta vejo sinhronizirani. To preprosto pomeni, da morate v določenih časovnih razmakih spajati spremembe iz glavne veje na stransko. Tako stranska veja vsebuje vse spremembe iz glavne veje, poleg tega pa tudi spremembe zaradi razvoja nove zmožnosti. Za sinhronizacij uporabljate možnost Spoji območje revizij. Ko je razvoj na stranski veji končan, lahko spojite spremembe nazaj na glavno vejo z uporabo možnosti Vključitev veje ali Spoji dve različni drevesi.

Another (fast) way to merge all changes from trunk to the feature branch is to use the TortoiseSVNMerge all... from the extended context menu (hold down the Shift key while you right click on the file).

Slika 4.60. The Merge-All Dialog

The Merge-All Dialog


This dialog is very easy. All you have to do is set the options for the merge, as described in “Možnosti spajanja”. The rest is done by TortoiseSVN automatically using merge tracking.

TortoiseSVN homepage