[nene]

Mul on Subversioni repositooriumis lisaks muule koodile ka ühe välise library lähtekood (paras hunnik faile). Libraryst tuleb välja uus versioon. Tõmban uue versiooni library kodulehelt alla. Nüüd tahaks lisada selle uue library versiooni oma repositooriumisse vana versiooni asemele.

Kõige lihtsam oleks muidugi vana versioon lihtsalt ära kustutada ja uus asemele panna, kuid see oleks meeletu raiskamine - vaid väike osa library koodist on kahe versiooni vahel muutunud. Seetõttu tahaks n.ö. tõmmata vaid need muudatused oma repositooriumisse: muuta vaid faile, mis on muutunud, lisada vaid failid, mis on lisandunud, ning eemaldada vaid failid, mis on eemaldatud.

Kuna library on suur, siis käsitsi seda protsessi kindlasti ette ei võta. Mõtlesin ka mingi skripti kirjutamise peale, kuid see tundub jalgratta leiutamisena - ma ei saa olla ainuke, kes sellist asja teha tahab. Katsusin googeldada, kuid ilmselt ei osanud oma päringut õieti sõnastada.

Oskab keegi nõu anda?

[e-Thug]

Ma võib olla ei lugenud õiget mõtet välja, aga kas uue versiooni failide svni dir-i kopeerimine ja svn commit, mille tagajärjel commititakse ainult praeguse versiooniga võrreldes muudetud failid, uute failide svn add+commit ning seejärel kaotatud failide repositoryst removeimine pole sobiv lahendus?

E: http://svnbook.red-bean.com/en/1.0/re16.html

[matik]

tee diff ja merge ära, mis seal siis keerulist on? kui sa ise selle libra koodi pole muutnud oma repos, siis konflikte ei teki ju?

[nene]

@e-Thug: selline asi töötab vaid siis kui mul on lihtsalt posu faile, aga minul on failid kataloogides ja siis veel alamkataloogides jne.

@matic: võibolla seletad täpsemalt kuidas ma seda diff'i ja merge'i teen. svn merge näikse töötavat vaid failide puhul mis juba on minu repositooriumis. Või olen ma millestki valesti aru saanud?

[matik]

no kui peale kopeerimine ei sobi, võid ju vana libra tõesti ära kustutada ja uuesti importida? kui sa ise pole muutusi teinud sinna, siis pole mergemist nagunii vajagi

[nene]

Asi on rohkem põhimõttes. Kui mingid failid on repositooriumis, siis võiks neil olla ka normaalne ajalugu. Muidugi ma võiks vana library lihtsalt ära kustutada ja uue asemele panna, aga see poleks õige.

Lisaks on selline kustutamine ja asendamine ka puhas kettapinna raiskamine. Antud juhul on library vaid mõni megabait ja see kadu on tühine, aga siiski hakkab imelik kui peale mitut sellist library versiooniuuendust moodustab nende uuendustega raisatud ruum enamuse repositooriumi mahust.

Nagu ma ütlesin, siis olen ma täiesti võimeline kirjutama skripti, mis teostaks selle mergemise. Aga mul on kangesti selline tunne, et minu probleemile on kusagil juba lahendus olemas ning sellist skripti kirjutades leiutaksin ma jalgratast.

[reneSharp]

Kui platvorm millel töötad on windows siis on olemas väga hea subversioni ui liides: tortoisesvn
http://tortoisesvn.net/
Põhiharus on juba muudetud kood
reposse lisad kõrvalharu kus on kood uuest versioonist.

loodud harust merge põhiharusse (howto :http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-merge.html#tsvn-dug-merge-range
)

[nene]

mnjaa.. aga see teeb ju kokkuvõttes ikkagi välja selle, et ma lisan reposse terve uue versiooni koodi, mitte üksnes muudatused.

[reneSharp]

Kui ise oleks antud probleemi ees siis mina lahendaks asja järgnevalt (puhtalt lehelt) :

Põhiharusse ülesse versioon 1 .
Ühtlasi saab see olema koht kus teen ainult omi muudatusi.
Põhiharusse ennem yhtegi muudatust ei tee kui olen loonud
kõrvalharu põhiharust
Mõte on selles et kui tuleb välja versioon 2 siis saan switchida põhiharust
ringi kõrvalharusse ning külmalt yle kopeerida failid uue versiooni omadega , kuna
kõrvalharusse omi muudatusi ei tee.
Olgu ära öeldud et branchimine ei tekita uusi faile juurde . repo browser võib sellise
mulje jätta ,kuid svn-i üks põhimõtteid on seda vältida,
jäädvustatakse vaid muudatused revisioni-te näol.
3.Peale commiti switchin tagasi põhiharusse kus merge-in muudatused
kõrvalharust põhiharusse mida sai just update-itud .

[inzinz]

No, ma oma projektide puhul kus enda tehtud baasraamistiku peale ehitan kasutan sellist lähenemist:
kopeerin uuendatud baasraamistiku kausta olemasoleva baasraamistiku kausta kõrvale nii et sisene struktuur on sama (näiteks base kausta kõrvale tekitan kausta base_new)
ja siis winmerge tooliga (windowsi jaoks, sobitub tortoisesvn otsa ja saab ka eraldi kasutada) syncin kaustade sisud ära, winmerge näitab ilusti ära mis failide sisud erinevad, mis fail või kaust kuskilt puudu on ja laseb shortcuttidega kiirelt faile üle kopeerida, kustutada, sisusid diff vaates võrrelda jne (endal diff vaade vajalik et üle vaadata mida muutnud olen et kõik ilusti kokku mergida) ja järjest teen kuni kaustade sisud on omavahel võrdsed.
Kui kõik sisu on omavahel sünkroniseeritud, siis kustutan base_new kausta ära ning commitin base kausta, ja tulemuseks ongi see et svn'i jõuab ainult muutus, ning ei pea kogu kremplit kustutama ja uuesti lisama.

Winmerge kasutan just seepärast et see näitab ära failide olemasolu/puudumisi et kui olen midagi kustutanud, siis saan ka kustutamise sünkroniseerida, kuid kui sul see raamistik ei ole nii tundlik selle suhtes kui paar üleliigset faili kuskil passima jääb, siis võid alati ka sisu otse üle kopeerida vana versiooni otsa ja siis commit tehes saadetakse svn'i jätkuvalt ainult muutused (sisulised muutused ja lisandunud failid siis).

Ehk on abiks...
EDIT:
Ise kasutan sellist lähenemist et vältida keerukamat branchimise ja mergimise loogikat pluss kuna mul vaja sünkroniseerida mitmeid eri versioone, siis pigem teen localis winmergega asjad jonksu ja siis alles commitin kui et jagelen branchimise ja mergemisega jne

[reneSharp]

[nene]