svn: zamień trunk na branch

Jaki jest najlepszy sposób, aby uczynić jedną z gałęzi repozytorium subversion nowym linkiem?

Nastąpił poważny przepis na cały system: rzeczy zostały przeniesione, przepisane, zastąpione, usunięte, przemianowane itp. Przepisany kod został przetestowany i jest gotowy do zastąpienia starego bagażnika.

Zasadniczo stara główna linia (Trunk 5) jest oznaczona i kończy się tutaj. Przepisana gałąź (Gałąź 6) ma stać się nową linią główną (Pień 7):

Bagażnik (1) -> Bagażnik (2) -> Bagażnik (5) -> × + -> nowy Bagażnik (7)
  \ \ |
  scalać widelec ???
    \ \ |
     + -> Oddział (3) -> Oddział (4) -> Oddział (6) - +

Wszystkie bieżące zmiany ze starego „Pnia” są już włączone do „Przepisanej gałęzi”

W jaki sposób mogę to zrobić?

Użyj svn move, aby przenieść zawartość starego pnia w inne miejsce, a następnie zmień nazwę gałęzi na trunk.

Zauważ, że kopiowanie i przenoszenie w svn działa jak operacje na plikach. Możesz ich używać do przenoszenia / kopiowania rzeczy w swoim repozytorium, a te zmiany są również wersjonowane. Pomyśl o „przeniesieniu” jako „kopiuj + usuń”.

[EDYCJA] Nilbus właśnie powiadomił mnie, że podczas korzystania z programu będą występować konflikty podczas łączenia svn move.

Nadal uważam, że jest to właściwe podejście. Spowoduje to konflikty, ale jeśli scalisz ostrożnie, istnieje szansa, że ​​nie stracisz żadnych danych. Jeśli to ci przeszkadza, użyj lepszego VCS, takiego jak Mercurial lub Git .

Zgadzam się z użyciem polecenia svn move do osiągnięcia tego celu.

Wiem, że inni uważają to za niezwykłe, ale ja lubię to robić w ten sposób. Kiedy mam gałąź funkcji i jestem gotowy do scalenia go z pniem, który również został znacząco zmodyfikowany, połączę go z nową gałęzią, zwykle o nazwie <FeatureBranchName>-Merged. Następnie rozwiązuję konflikty i testuję scalony kod. Po zakończeniu przenoszę bagażnik do folderu tagów, aby nic nie zgubić. Wreszcie przenoszę <FeatureBranchName>-Mergedsię do bagażnika.

Ponadto wolę unikać kopii roboczej podczas wykonywania ruchów, oto przykłady poleceń:

svn move https://SVNUrl/svn/Repo/trunk https://SVNUrl/svn/Repo/tags/AnyName

svn move https://SVNUrl/svn/Repo/branches/BranchName-Merged https://SVNUrl/svn/Repo/trunk

Uwaga: używam 1.5

Właśnie ostatnio przyglądałem się temu problemowi i rozwiązaniem, z którego byłem bardzo zadowolony, było działanie

svn merge --ignore-ancestry trunk-url branch-url

na kopii roboczej mojego bagażnika.

Nie jest to próba wprowadzania zmian w sposób historyczny (utrzymanie zmian w pniu). Po prostu „stosuje różnicę” między pniem a gałęzią. Nie spowoduje to żadnych konfliktów dla użytkowników w plikach, które nie zostały zmodyfikowane. Jednak utracisz informacje historyczne z oddziału, ale dzieje się tak, gdy i tak dokonasz scalenia.

Zaleca się wprowadzenie tych zmian za pomocą narzędzia przeglądarki repozytorium.

Próba dużych operacji usuwania i przenoszenia za pośrednictwem kopii roboczej to świetny sposób na zabicie kopii roboczej. Jeśli jesteś zmuszony do używania kopii roboczej, wykonaj zatwierdzanie przyrostowe po każdej operacji usuwania lub przenoszenia i ZAKTUALIZUJ swoją kopię roboczą po każdym zatwierdzeniu.

Jeśli chcesz, aby gałąź stała się nowym linkiem (tj.) Pozbyła się wszystkich zmian w linii głównej, które zostały wprowadzone od czasu utworzenia gałęzi, możesz: 1. Utworzyć gałąź linii głównej (do celów kopii zapasowej) 2. "cofnąć zmiany "na linii głównej (wybierz wszystkie wersje po utworzeniu gałęzi 3. Scal gałąź z powrotem do linii głównej.

Historia powinna tak pozostać.

Pozdrawiam, Roger

Rozwiązania @Aaron Digulla i @kementeus są wykonalne. W przypadku repozytoriów Subversion 1.4 operacje kopiowania / przenoszenia mogą utrudnić przyszłą migrację do innej struktury repozytoriów lub podział repozytoriów.

Uważam, że ulepszenia 1.5 obejmują lepszą rozdzielczość historii przenoszenia / kopiowania, więc prawdopodobnie nie byłby to problem dla repozytorium 1.5.

W przypadku repozytorium 1.4 zalecałbym użycie svnadmin dumpi svndumpfilterwykonanie przeniesienia istniejącego pnia w inne miejsce, a następnie przeniesienie gałęzi do pnia za pomocą tego samego mechanizmu. Załaduj dwa pliki zrzutu do repozytorium testowego, sprawdź, a następnie przenieś je do środowiska produkcyjnego.

Oczywiście przed rozpoczęciem wykonaj kopię zapasową istniejącego repozytorium.

Pozwala to zachować historię bez jawnego rejestrowania przeniesienia / kopii i ułatwia przyszłą reorganizację, zachowując historię.

Edycja: zgodnie z żądaniem, dokumentacja zachowania 1.4, z książki 1.4 Red-Bean, Filtering Repository History

Również skopiowane ścieżki mogą sprawić trochę problemów. Subversion obsługuje operacje kopiowania w repozytorium, gdzie nowa ścieżka jest tworzona przez kopiowanie już istniejącej ścieżki. Możliwe, że w którymś momencie życia repozytorium mogłeś skopiować plik lub katalog z jakiejś svndumpfilterwykluczającej lokalizacji do lokalizacji, którą on zawiera. Aby dane zrzutu były samowystarczalne,svndumpfiltermusi nadal pokazywać dodanie nowej ścieżki - w tym zawartość wszelkich plików utworzonych przez kopię - i nie reprezentować tego dodatku jako kopii ze źródła, które nie będzie istniało w strumieniu danych z odfiltrowanego zrzutu. Ale ponieważ format zrzutu repozytorium Subversion pokazuje tylko to, co zostało zmienione w każdej wersji, zawartość źródła kopiowania może nie być łatwo dostępna. Jeśli podejrzewasz, że masz jakiekolwiek kopie tego rodzaju w swoim repozytorium, możesz chcieć przemyśleć swój zestaw dołączonych / wykluczonych ścieżek, być może włączając ścieżki, które służyły jako źródła twoich kłopotliwych operacji kopiowania.

Dotyczy to migracji / reorganizacji przy użyciu svndumpfilter. Są chwile, kiedy odrobina dodatkowej pracy teraz może zaoszczędzić wiele dodatkowej pracy później, a dzięki łatwemu wykorzystaniu svndumpfilterdostępnej dla przyszłych migracji / reorganizacji ryzyko zmniejsza się przy stosunkowo niskich kosztach.

Chociaż powyższe odpowiedzi będą działać, nie są one najlepszą praktyką. Najnowszy serwer svn i ścieżka klienta łączą się dla Ciebie. Więc svn wie, które wersje zostały scalone w gałąź i skąd. To bardzo pomaga w utrzymywaniu aktualności gałęzi, a następnie łączeniu jej z powrotem w pniu.

Bez względu na to, której wersji Subversion używasz, istnieje najlepsza metoda postępowania w celu uzyskania zmian w gałęzi z powrotem do linii głównej. Jest to opisane w podręczniku Subversion: Kontrola wersji z Subversion, rozdział 4. Rozgałęzianie i łączenie, utrzymywanie synchronizacji gałęzi .

To naprawdę dziwna / nietypowa konfiguracja w SVN, nawet jeśli myślę, że wcale nie jest to „dobra praktyka”, i tak myślę, że możesz zrobić coś takiego:

• Sprawdź wszystkie źródła (svn co therootsourcetree)
• Usuń bagażnik (svn rm trunk)
• Skopiuj gałąź do pnia (gałęzie svn cp / thebranch / trunk)
• Usuń gałąź (gałęzie svn rm / thebranch)
• Zatwierdź zmiany

Powodzenia