2009-05-13 13 views
8

Mam kilka projektów z bardzo dużą nakładającą się bazą kodową. Niedawno zaczęliśmy używać SVN, więc próbuję dowiedzieć się, jak powinienem go używać.Najlepsze metody kontroli wersji z wieloma projektami

Problem polega na tym, że kończąc zadanie w jednym projekcie, uruchamiam zadanie na innym, z pewnym nakładaniem się. Często zdarza się, że jest to również rozwój przerywany. Tak więc, mój kod nigdy nie jest w stanie całkowicie stabilnym, co sprawia, że ​​czuję się komfortowo.

Powoduje to, że tak naprawdę nie używamy systemu VC, co jest BARDZO złe, wszyscy wiemy ... więc, sugestie?

Odpowiedz

1

Sprawdź osobistą gałąź kodu i scal zmiany. Przynajmniej będziesz mieć kontrolę wersji dla własnych zmian, na wypadek gdybyś musiał wycofać. Kiedy już poczujesz się komfortowo ze stanem, w którym znajduje się twój oddział, połącz tę gałąź z powrotem w bagażniku.

Można również sprawdzić oddział dla każdego zadania, zamiast jednego dla każdej osoby. Możesz również scalić zmiany w gałęzi z pnia, jeśli ktoś zmieni bagażnik i chcesz, aby oddział odzwierciedlił zmiany.

Jest to popularny sposób korzystania z SVN, mimo że istnieją inne przepływy pracy. Pracowałem nad projektami, w których bałem się popełnić (prawdopodobnie przerwałbym konstrukcję), ponieważ nie używaliśmy efektywnie rozgałęzień.

Rozgałęzianie jest bardzo pomocne w przepływie pracy, użyj go, aż poczujesz się komfortowo z pomysłem łączenia.

Edytuj: "Sprawdzanie oddziału" odnosi się do tworzenia gałęzi w folderze Oddziały, a następnie sprawdzanie tej gałęzi. Standardowa struktura repozytorium svn składa się z folderów trunk, tagów i gałęzi w katalogu głównym.

0

W TFS, jesteś w stanie stworzyć "Zestawy półek" (nie jestem pewien, co mieliby nazwać w innych dostawców kontroli źródła). Kiedy odkładasz jakiś kod, zapisujesz go w repozytorium, ale go nie wpisujesz.

Powodem tego jest to, że jeśli pracujesz nad błędem XXXX i naprawiasz połowę kodu, ale to nie jest stabilny, a nie "check-in-stanie", ale zostaniesz przypisany do NewFeature YYYY, nie powinieneś kontynuować pracy z tą samą bazą kodu. Powinieneś "Shelf" swój kod błędu XXXX, a następnie odesłać swój lokalny codebase do najnowszego kodu zameldowania i wprowadzić NewFeature YYYY.

W ten sposób przechowujesz kontrolerze atomowej. Nie musisz martwić się o utratę pracy, ponieważ nadal jest ona przechowywana w repozytorium (więc jeśli twój komputer wpadnie w płomienie, nie musisz się rozpłakać) i nie mieszasz poprawek do XXXX z nowym kodem dla YYYY. Następnie, gdy zostaniesz poproszony o powrót do XXXX (zakładając, że zaznaczyłeś YYYY), możesz po prostu odrzucić swój "zestaw półek" i wskoczyć z powrotem do tego miejsca, w którym przerwałeś.

0

Albo zaakceptuj, że kod w SVN nie jest w całkowicie stabilnym stanie i mimo to sprawdź (i zarezerwuj czas na stabilizację i refaktoryzację co X dni/tygodnie, aby kod nie za bardzo się pogorszył).

Możesz zmusić swój zespół do pracy w bardziej uporządkowany sposób przy minimalnym rozwoju opartym na przerywaniu, aby umożliwić sprawdzenie dobrego kodu.

Pierwsza opcja nie jest idealna (ale lepiej niż brak kontroli źródła), druga jest prawdopodobnie niemożliwa - nie ma trzeciej opcji.

Jeśli nie masz czasu, aby uzyskać stabilny kod, nie masz czasu na rozgałęzianie i scalanie.

+0

Problem polega na tym, że jesteśmy firmą 7-osobową (2 inżynierów), więc nie możemy sobie pozwolić na taką strukturę. Również "zespół" to tylko ja. –

1

Więc mój kod nie jest tak naprawdę w zupełnie stanie stabilnym, że czuję się komfortowo zameldowaniu.

Dlaczego tak jest?
Jeśli Twój oddział jest odpowiedni do twojej pracy (na przykład z dobrą konwencją nazewnictwa), każdy będzie wiedział, że jego HEAD nie zawsze jest stabilny.
W tej gałęzi "działającej" po prostu umieść znacznik po drodze, aby wskazać pewne "stabilne punkty kodowe" (które mogą być następnie sprawdzane przez każdy tester do wdrożenia).
Każda inna wersja tej gałęzi roboczej jest właśnie wprowadzana do zapisywania zmian, nawet jeśli obecny stan nie jest stabilny.

Później łączysz wszystkie gałęzie, które mają reprezentować stan stabilny.

0

W rozproszonych systemach kontroli sourcowej, takich jak GIT, zobowiązujesz się do lokalnego repozytorium. Dopiero po naciśnięciu kodu jest on "zatwierdzony" do zdalnego repozytorium.

W ten sposób znacznie łatwiej jest "bezpiecznie" wykonać pracę pomiędzy.

Powiązane problemy