Czy różne klony git-svn tego samego repozytorium svn mogą oczekiwać, że będą mogły udostępniać zmiany w git svn dcommit?

[5]} ostatnio dużo z tym eksperymentowałem i myślę, że udało mi się wymyślić konfigurację, która nieco działa. Tak, jest to ścisły system tylko dla rebase, tak to skomplikowane, ale możesz używać Gita do pracy lokalnie (szybkość, historia, stash, indeks, itp.).

Możesz używać gałęzi za kulisami, kiedy współpracujesz z innymi użytkownikami Gita w swoim zespole, ale nie eksperymentowałeś z tym osobiście. Tak długo, jak linearyzować dziennik przed dcommitting powinien praca.

Oto krótka wersja (powtarza wiele tego, co już zostało powiedziane):

Nie jest to jednak możliwe, ponieważ nie jest to możliwe.]}
1. Init a "gołe" repo na tym samym serwerze
2. Push from the fecthing repo to the GOE repo
3. niech deweloperzy sklonują nagie repo, a następnie
   1. git svn init svnurl aby skonfigurować git-svn remote i
   2. git update-ref refs/remotes/git-svn refs/remotes/origin/master więc git-svn ma wskaźnik do rewizji
4. automatycznie (commit hook) mają" pobieranie " repo svn rebase i wciskają do nagiego repo
5. deweloperzy wyciągają z nagiego repo z git pull --rebase
6. Programiści uruchamiający git svn dcommit muszą najpierw powtórzyć update-ref powyżej w przypadku nowszych wersji pochodzących z SVN.

Jest ilustracja przepływu pracy na tej stronie (potrzebuję więcej punktów reputacji, zanim będę mógł wstawić obraz). Update: Here we go:

Kiedyś tworzyłem początkowy klon git svn, a następnie udostępniałem he .git wśród programistów używających git, więc mieliśmy dokładnie te same referencje.

Wydawało się, że działa poprawnie, ponieważ byliśmy w stanie używać "specyficznych funkcji Gita" między użytkownikami Gita, tak długo jak pozostaliśmy w liniowym drzewie (tj. rebasing zamiast scalania).

Jak tylko wejdziesz do wydania" distributed", lepiej Ci będzie z jednym nagim Git repo sklonowanym wśród deweloperów.
Jeśli chodzi o fazę eksportu-importu do publicznego SVN repo, dla innych do wykorzystania, Skrypty
git2svn i svn2git mogą pomóc w hermetyzacji magii.

Inne uwagi dotyczące pracy w repozytoriach GIT i SVN można znaleźć w pytaniu "Workflow and help with git, 2 projekty svn i jeden "workcopy""

Istnieje narzędzie, które rozwiązuje problem współdzielenia repozytorium Git zsynchronizowanego z repozytorium Subversion.

SubGit jest dwukierunkowym serwerowym serwerem lustrzanym Git-SVN.

Można zainstalować SubGit w repozytorium Subversion i uzyskać repozytorium Git automatycznie zsynchronizowane z SVN:

$ subgit configure $SVN_REPOS
# Adjust $SVN_REPOS/conf/subgit.conf to specify branches, tags and other options;
# Adjust $SVN_REPOS/conf/authors.txt to specify git & svn authors mapping
$ subgit install $SVN_REPOS
...
$ INSTALLATION SUCCESSFUL

SubGit instaluje haki przed zatwierdzeniem i po zatwierdzeniu do repozytorium Subversion, haki przed odbiorem i po odebraniu do repozytorium Git. W rezultacie natychmiast przekłada przychodzące modyfikacje ze stron SVN i Git. Po instalacji SubGit deweloperzy mogą użyć dowolnego klienta Git do klonowania i pracy z repozytorium Git.

SubGit nie opiera się na git-svn, używa własnego silnika tłumaczeń, który opracował nasz zespół. Więcej szczegółów na ten temat można znaleźć w porównanie SubGit vs.Git-svn . Ogólna dokumentacja SubGit jest dostępna tutaj .

Wersja 1.0 SubGit wymaga lokalnego dostępu do repozytorium Subversion, czyli repozytoriów SVN i Git muszą przebywać na tym samym żywicielu. Ale w wersji 2.0 wprowadzimy tryb proxy Git, kiedy repozytoria Subversion i Git mogą być zlokalizowane w dowolnym miejscu i tylko repozytoria Git mają zainstalowany SubGit, tzn. repozytoria Subversion pozostają nietknięte.

SubGit jest produktem komercyjnym. Jest bezpłatny dla projektów open-source, akademickich, a także dla projektów z maksymalnie 10 osobami.

Disclaimer: jestem jednym z deweloperów SubGit.

Znalazłem ten wpis na blogu , który sugeruje pozostawienie oddzielnej gałęzi do synchronizacji z repozytorium Subversion, tak że nadal będzie można wykonać push / pull w gałęzi master.

Jednym z problemów, które dostrzegam w git-svn jest to, że przechowuje on git-svn-id w komentarzu commit ; ponieważ przepisuje ten commit, zmienia to SHA1, więc nie możesz go wcisnąć gdziekolwiek ludzie będą go udostępniać.

Wolę bzr-svn, ponieważ zamiast tego przechowuje bzr revid w zdalnej rewizji SVN używając właściwości SVN revision, co oznacza brak lokalnego przepisywania rewizji. Ma również pożądaną właściwość, że dwa niezależne ciągi tej samej gałęzi SVN powstanie identycznych i interoperacyjnych oddziałów bzr.