Mój zespół używa SVN do kontroli źródła. Ostatnio pracuję nad oddziałem, w którym sporadycznie znika z pnia i jest to dość denerwujące doświadczenie (por. Joel Spolsky's "Subversion Story #1"), więc szukałem alternatywnych sposobów zarządzania oddziałami i łączeniem. Biorąc pod uwagę, że scentralizowane repozytorium SVN nie podlega negocjacjom, chciałbym mieć zestaw narzędzi spełniających następujące warunki.Narzędzia do utrzymywania oddziałów w SVN
Pełna historia zmian powinna być przechowywana w SVN dla obu linii i gałęzi.
Połączenie w dowolnym kierunku (i potencjalnie krzyżowanie) powinno być stosunkowo bezbolesne.
Scalanie historii powinno być przechowywane w SVN w największym możliwym stopniu.
Szukałem zarówno git-svn i bzr-svn i nie wydaje się do pracy — Zasadniczo, biorąc pod uwagę historię zmian można je wyeksportować z repozytorium SVN, mogą one nie wydają się zrobić żadnego Lepszy przetwarzanie zadań scala się z wersją SVN. Na przykład po sklonowaniu repozytorium przy użyciu git, historia wersji dla mojego oddziału pokazuje oryginalną gałąź z pnia, ale git nie "widzi" żadnego z przejściowych SVN łączy się jako "natywny" scala — historia wersji jest jedna długa linia. W rezultacie każda próba połączenia z pnia w git przyniosła tyle samo konfliktów co połączenie SVN. (Poza tym, git-svn documentation wyraźnie ostrzega przed użyciem git scalić między oddziałami.)
Czy istnieje sposób, aby dostosować mój workflow aby git spełniać powyższe wymagania? Może po prostu potrzebuję wskazówek lub trików (lub osobnego narzędzia do łączenia?), Aby pomóc SVN być lepszym w łączeniu się w gałęzie?
Wygląda na to, że musisz po prostu przekonać swój zespół do korzystania z git. : P – Amber
Myślę, że niestety, masz do czynienia z faktem, że SVN ma ograniczoną zdolność do łączenia oddziałów - i tak długo, jak twoje centralne repozytorium jest repozytorium SVN, trudno jest uzyskać dowolną ilość magii git ocalić Cię. Jestem z pewnością ciekawy, czy są jakieś dobre działające kludy! – Cascabel