Copiere/îmbinare retroactivă

Uneori, un utilizator va copia fișiere utilizând Windows Explorer și le va angaja atunci când ar fi trebuit să efectueze o copie la nivel de repository svn sau o îmbinare. Astfel, SVN nu are o urmărire corespunzătoare a acestor schimbări. Odată ce am aflat despre acest lucru, daunele sunt deja făcute și s-ar putea să fi fost o mulțime de editări ulterioare la fișierele în cauză. Este important să nu pierdeți nici această parte a istoriei. Există ceva ce pot face pentru a îmbunătăți în mod retroactiv lucrurile în depozit atunci când aflu că aceste situații au avut loc?

Mai exact, am două scenarii, în funcție de existența sau nu a fișierului țintă. În primul sceanrio, (1) utilizatorul a efectuat o adăugare care nu a fost înregistrată ca o copie. În cel de-al doilea scenariu, (2) utilizatorul a efectuat o actualizare care nu a înregistrat ca o fuzionare.

În plus, atât sursa, cât și dosarul țintă au fost supuse unor actualizări ulterioare, care au fost, de asemenea, angajate. Uneori, aceste modificări ulterioare au fost făcute și manuală pentru ambele părți și, prin urmare, fără o coreinfo.

POSIBILITATE: S-ar putea adăuga manual o revizie mergeinfo la ajutorul revizuirii anterioare? Dacă da, cum fac asta? Luați în considerare ambele scenarii.

8
@Atilla, oh da. De către alți utilizatori. Poate cu luni în urmă. Este posibil ca fișierele să aibă și modificări ulterioare importante.
adăugat autor Jason Kresowaty, sursa
Vrei să spui că editările la fișierele copiate prost au fost angajate în depozit sau sunt în așteptare în copia locală?
adăugat autor Attila, sursa

3 răspunsuri

Iată scenariile pe care le pot gândi și cum le pot rezolva (dacă este posibil):

1) fișierele au fost copiate și au fost făcute modificări (la adresa URL inițială)

1a) dacă sucursala nu are încă aceste fișiere:

  • svn-copiați fișierele (sau directorul lor anexat) la ramură (aceasta își păstrează istoricul)
  • dacă nu s-au efectuat alte modificări la acele fișiere specifice din portbagaj, reveniți la portbagaj pentru acele fișiere/directorul care se anexează la revizuire chiar înaintea copiei
  • în cazul în care au existat modificări în portbagaj la aceste fișiere, s-ar putea să reuși să obțineți modificările aparținând filialei făcând o îmbinare inversă: aceasta ar trebui să aibă succes dacă unele dintre modificări nu s-ar suprapune

1b) dacă sucursala are deja acele fișiere:

  • svn-îmbinați modificările trunchiului la ramură
  • aceleași considerații pentru trunchi ca la 1a)

2) fișierele au fost copiate, au fost făcute modificări, dar nu au fost comise (la adresa URL originală, deoarece copia nu a schimbat-o)

Note: since the modifications have not been committed yet, there is no history to preserve, also nothing to do with the trunk

2a) dacă sucursala nu are încă aceste fișiere:

  • face o copie fizică a fișierelor/directorului copiat greșit
  • ștergeți dosarul care încalcă drepturile din copia de lucru a sucursalei
  • copiați/mutați fișierele/directorul copiat anterior în locul corespunzător din copia de lucru a sucursalei
  • adăugați fișierele în ramură

2b) dacă sucursala are deja aceste fișiere:

  • face o copie fizică a fișierelor/directorului copiat greșit
  • ștergeți dosarul care încalcă drepturile din copia de lucru a sucursalei
  • actualizați copia de lucru a sucursalei
  • îmbinați (*) fișierele/directorul copiat anterior cu omologii lor din copia de lucru curentă a sucursalei
  • adăugați fișierele în ramură

(*) utilizați orice instrument de îmbinare obișnuit pentru lucrare, de ex. WinMerge


Update: after your edit I understand your situation better (the above was with the assumption that after the manual copy the URL of the copied folder still pointed to the trunk)

You could try using svn propset --revprop -r snv:mergeinfo (unless blocked by a pre-revprop-change hook) on the branch to "fix" the merge info, but I believe you will have to "fix" all subsequent revisions' mergeinfo as well since svn uses this information for fome of its operations (e.g. merges); also, because of the latter, you will have to be very careful about the updated contents.

A better option would be, I think, to just update the log at the revision of the incorrect-commit-to the-branch to include the revision of the trunk the copied files refer to. This way the information is available if needed but no risk of messing up svn's future operations. The big drawback of this approach is that merging the branch back to trunk might have some conflicts that will have to be resolved (as the merge info was not updated). The command to do this opetion is svn propset --revprop -r svn:log

1
adăugat
dacă cineva tocmai a făcut acest lucru și am doar o revizuire pentru a face față, cred că setarea informații de îmbinare ar trebui să fie de ajuns, nu svn comanda merge nu ceva special ?, ea constată ce trebuie să fie fuzionat, copia aceste dosare peste, , el stochează delta oricum - punctul meu este, manual winmerge comite + setarea de îmbinare info ar trebui să fie exact egale cu svn merge + svn comite?
adăugat autor Kalpesh Soni, sursa

Presupunând că fișierul copiat nu a fost adăugat în noua locație, primul meu gând este să fac următoarele:

  1. Make a backup of the current WC file(s) that were moved
  2. Do a repo move (to preserve history) of the files in #1;
  3. svn up to get the WC in line
  4. Ensure the file(s) were merged correctly and if not use the backups from #1 to get the file(s) in sync.
  5. Commit and move on
0
adăugat
A fost adăugată și angajată. Poate săptămâni sau luni în urmă. Cu modificările ulterioare comise atât la versiunea originală, cât și la "copia" greșită pe care SVN nu o monitorizează în mod corespunzător. Asta am vrut să spun prin "daunele s-au făcut". Îmi pare rău dacă nu eram destul de clar.
adăugat autor Jason Kresowaty, sursa

Soluția mea nu este tehnologică. Mai degrabă cred că trebuie să-i înveți pe oamenii tăi că fac ceva în neregulă și să le arate cum să facă așa. Nimic de a fi supărat. Uneori, oamenii (inclusiv eu) fac ceva stupid deoarece nu și-au dat seama că există o cale mai bună sau pentru că ei încă nu au înțeles calea cea mai bună.

Dacă acest lucru este cu adevărat recurent, rețineți greșelile și succesele. Testați rezultatele pe o tablă și faceți-i jocul. Nu alege pe oameni. După ceva timp problema va scădea.

0
adăugat