Zaawansowane techniki subwersji, czego mi brakuje?

Zacząłem używać SVN około 9 miesięcy temu i co najmniej zmieniło grę. Chociaż czuję, że wciąż jestem trochę zagubiony. Wydaje mi się, że jest o wiele więcej rzeczy, które muszę wykorzystać, aby naprawdę przyspieszyć tworzenie aplikacji.

Na przykład

Chciałbym móc poddać kwarantannie wszelkie niestabilne / poważne zmiany w jakimś rodzaju „sub-repozytorium” lub coś w tym rodzaju. Uważam, że poważne zmiany utrudniają drobne poprawki błędów, które są bardzo pilne. Jak mogę wypchnąć jedną prostą aktualizację bez wypychania niekompletnego lub uszkodzonego kodu?

Aby zaadresować swój przykład, masz trzy możliwości:

1. Możesz zatwierdzać pojedyncze pliki. Jeśli korzystasz z IDE w celu uzyskania dostępu do repozytorium, najprawdopodobniej ma on widok, aby zaznaczyć lub odznaczyć pojedyncze pliki przed zatwierdzeniem. W wierszu polecenia wpisujesz, svn commit file1 path1/file2 path2aby zatwierdzić plik1, ścieżkę1 / plik2 i każdą zmianę w ścieżce2.
2. Możesz wykonywać różne kopie robocze. Pracujesz nad swoją dużą funkcją w standardowej kopii roboczej i otrzymujesz informacje o pilnym błędzie. Możesz pobrać swoje repozytorium do innego katalogu i naprawić błąd w tej drugiej kopii roboczej. Możesz nawet sprawdzić tylko podkatalog z komponentem, w którym występuje błąd. Po usunięciu błędu możesz zatwierdzić drugą kopię roboczą bez angażowania pracy w dużą funkcję. EDYCJA: Ten sposób jest również opisany w odpowiedzi Anny Lear.
3. Tworzysz gałąź dla pracy nad twoim obiektem. W tym celu użyj polecenia kopiowania. Jeśli używasz standardowego DTP dla repozytorium (katalogi z Nazwa_projektu i podkatalogów z nazwiskami bagażniku, tagi i gałęzie, pień zawierający projekt) można skorzystać z kopiowaniem polecenie svn jak następuje, aby utworzyć oddział: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Teraz możesz przełączyć kopię roboczą do nowej lokalizacji: przełącznik svn svn switch svn://hostname/projectname/branches/branch-for-feature-X. Jeśli przełączysz się w tryb naprawiania błędów, zatwierdzasz rzeczywiste zmiany, przełączasz kopię roboczą z powrotem do linii głównej, naprawiasz błąd i zatwierdzasz, a następnie przełączasz kopię roboczą z powrotem do gałęzi funkcji. Jeśli jesteś gotowy na rozwój tej funkcji, możesz połączyć ją z powrotem do linii głównej.

W opisanym prostym przypadku zwykle używasz numeru 1 (używam najczęściej), czasem nr 2. Praca z gałęziami (przypadek nr 3) jest bardziej skomplikowana ( czytaj więcej ), ale pozwala na więcej sztuczek. Ale gałęzie pasujące do twojego opisu podrepozytorium.

Poza twoim przykładem niewiele mogę powiedzieć. Subversion ma wiele rzeczy, ale nie wiem, czego już używasz i czego potrzebujesz do swojego projektu. Aby dowiedzieć się więcej o SVN, SVN-Book jest doskonałym źródłem: http://svnbook.red-bean.com/

Możesz pobrać kod do różnych piaskownic zamiast pobierać jedną kopię i wprowadzać tam wszystkie zmiany.

Więc możesz mieć strukturę folderów, która wygląda mniej więcej tak:

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

itp.

Wszystkie można wyewidencjonować z tej samej lokalizacji w Twojej SVN, np http://mysvnrepo/trunk.

W ten sposób możesz zatwierdzić z poziomu piaskownicy naprawiania błędów bez wpływu na te rozwijające funkcje, chociaż musisz uruchomić svn updatez innych piaskownic, aby zatwierdzić zmiany dotyczące poprawki błędu.

Czy w ogóle spojrzałeś na gałęzie Subversion ?

Jedną z powszechnych technik jest utrzymanie stabilności Trunk, stosując krytyczne poprawki zgodnie z wymaganiami. Następnie tworzysz gałąź dla każdego nowego znaczącego dzieła. Programiści pracujący nad tym projektem sprawdzają oddział i zobowiązują się do niego. Nie wpływa to na pień, dopóki nie zdecydujesz się połączyć gałęzi z powrotem do pnia głównego w ramach ostatecznej integracji.

Innym podejściem jest posiadanie gałęzi dla konkretnego wydania, aby uniknąć przypadkowej pracy nad linią powodującą problemy. Możesz naprawić błąd „Release Branch” zgodnie z wymaganiami, a następnie złożyć poprawki z powrotem do bagażnika, gdy będą gotowe.

Twoi programiści mogą pobrać wiele kopii roboczych - pień i dowolne gałęzie - lub mogą przełączać się między pniem a określoną gałęzią za pomocą svn switchpolecenia.

Nie polecam posiadania wielu „roboczych piaskownic” kopii roboczych, które przechowujesz osobno przy kasie, ponieważ (a) zabrania to współpracy z innymi i (b) zbyt łatwo będzie przypadkowo wprowadzić niedziałające, ale jeszcze zmiany w głównej części.

Obecny rozmiar mojej kopii roboczej wynosi 10 GB, z ponad 50 000 plików. Mogę mieć kilka kopii dla różnych gałęzi, ale tworzenie nowej kopii zajmuje trochę czasu!

Kiedy pojawia się pilny błąd, zwykle zapisuję wszystkie zmiany w łatce, wszystko cofam, pracuję nad błędem i zatwierdzam, a następnie stosuję zapisaną łatkę ... O wiele łatwiejsze i szybsze niż uzyskanie nowej kopii roboczej. Gdybym musiał to robić często, miałbym dwie kopie robocze: jedną do długoterminowych zmian, drugą do naprawiania błędów.