Kontrola wersji oparta na pamięci przenośnej?

9

Tworzę osobiste projekty na dwóch komputerach bez korzystania ze wspólnego serwera lub połączenia sieciowego między nimi.

Czy jakieś popularne systemy kontroli wersji niezawodnie obsługują korzystanie z przenośnej pamięci masowej (takiej jak urządzenie flash USB) jako wspólnego repozytorium?

version-control

— billpg
źródło

Dlaczego chcesz / potrzebujesz korzystać z przenośnej pamięci?

— Bernard,

Aby przenosić kod między dwoma komputerami w taki sam sposób, jak zwykły system kontroli wersji z udostępnionym serwerem. (Nie mam wspólnego serwera.)

— billpg

Kiedyś korzystałem z zestawu repozytoriów rtęciowych na dysku flash USB, aby aktualizować narzędzia produkcyjne w fabryce i działało to naprawdę dobrze. Możesz nawet zobaczyć, kiedy technicy na stronie modyfikowali kod na komputerze lokalnym, gdy Cię nie było, i scalali (lub odrzucali) ich zmiany przed zsynchronizowaniem ich z powrotem na dysk flash.

— Mark Booth,

Tutaj już powiedziano, że SVN obsługuje pamięć lokalną i możesz korzystać z usb. Ale wolę przechowywać DB w moim prywatnym folderze DropBox;) Możesz również korzystać z wielu bezpłatnych usług (takich jak assemblela lub tfs.visualstudio.com)

— Pavel Voronin,

31

Użyj DVCS, takich jak Git lub Mercurial .

Rozproszone systemy kontroli wersji nie mają wspólnego centralnego serwera.

Dzięki DVCS każda kopia repozytorium zawiera pełną historię - wszystko. Oznacza to, że w przypadku użycia na kluczu USB wszelkie zmiany, które wprowadzisz, zostaną wprowadzone w repozytorium na kluczu USB, a po przeniesieniu między komputerami zachowa tę historię.

— Oded
źródło

9

A jeśli używałeś github, nie musiałbyś nawet nosić ze sobą dysku USB

— CamelBlues

Dziękuję Ci. Czy można skonfigurować używanie przenośnego magazynu jako repozytorium?

— billpg

@billpg - Tak. Po prostu żyje w strukturze katalogów.

— Oded

@CamelBlues lub bitbucket lub kilnhg lub prawdopodobnie różne inne, które mogą, ale nie muszą być odpowiednie ...

— Murph

3

Mam swoje główne osobiste repozytoria Mercurial na DropBox. Działa świetnie i automatycznie implementuje tworzenie kopii zapasowych (ponieważ DropBox raczej nie zniknie w tym samym czasie, gdy stracę wszystkie komputery).

— David Thornley,

7

Oprócz GIT, Mercurial itp. Zasugerowanych powyżej, spójrz także na Fossil - Zaletą tego jest to, że pliki binarne w czasie wykonywania są małe (około 1 MB dla Windows i Linux), wymagana jest przenośna i zerowa instalacja. Dlatego, w przeciwieństwie do innych (o ile mi wiadomo), można go umieścić na urządzeniu pamięci masowej i uruchomić na dowolnym komputerze, do którego podłączona jest pamięć, bez konieczności najpierw instalowania aplikacji na komputerze. Obejmuje Wiki i system śledzenia zmian / błędów z repozytorium. Ma również wbudowane GUI.

Nie używałem go poważnie (głównie używam GIT), ale byłem pod wrażeniem jego lekkości, a włączenie Wiki i narzędzia do śledzenia defektów czyni go idealnym do małych projektów. Moją jedyną obawą było to, że niektóre z bardziej zaawansowanych funkcji GIT mogą nie być możliwe, aw przeciwieństwie do GIT społeczność użytkowników nie jest tak duża, że łatwo jest znaleźć odpowiedzi na pytania.

— mattnz
źródło

Chociaż Git bierze przykazanie uniksowe, aby zrobić jedną rzecz i zrobić to dobrze, poważnie, możesz mieć te funkcje w Git poprzez rozszerzenia takie jak Ticgit (system sprzedaży biletów) i Gollum (wiki oparte na repozytorium).

— Jason Lewis

@Jason Lewis: Masz rację, a ponieważ jest to oprogramowanie typu open source, możesz go zmodyfikować tak, aby spełniało twoje wymagania, tak więc GIT (lub dowolne inne narzędzie) może być wszystkim dla każdego (kogo można niepokoić, ma wolny czas i zasoby) aby pobrać, zainstalować i debugować wszystkie „wtyczki”. Wszystko, co powiedziałem, to rozwiązanie, które „Po prostu działa od

— razu po

1

Korzystanie z DCVS jest prawdopodobnie dobrym pomysłem, ale nie jest to jedyna opcja.

Mam małe repozytorium CVS na pendrivie USB. Kiedy chcę uzyskać do niego dostęp, po prostu muszę użyć ścieżki katalogu głównego repozytorium cvs -d <path>lub ustawić $CVSROOTtę ścieżkę (co oczywiście wymaga zamontowania napędu systemowego w systemie).

Jeśli jesteś już przyzwyczajony do korzystania z CVS, powinno to być wykonalne. To samo powinno mieć zastosowanie do SVN. Oznacza to po prostu, że twoje centralne repozytorium znajduje się na pendrivie i nie zawsze jest widoczne.

Istnieją argumenty przemawiające za użyciem DCVS zamiast ogólnie CVS. Nie sądzę, aby na te argumenty miał szczególny wpływ to, czy centralne repozytorium znajduje się na dysku USB, czy gdzie indziej. Na przykład równie łatwo można utworzyć repozytorium git na dysku USB.

— Keith Thompson
źródło

1

Zwykle nie jestem wielkim fanem DVCS, ale myślę, że DVCS byłoby lepsze w tym przypadku. Problem z nierozproszonym VCS polega na tym, że repo jest pojedynczym punktem awarii. Jeśli to siedzi w centrum danych z kontrolowanym klimatem i zostanie wsparte regularnie, to nie jest wielka sprawa - ale coś w pamięci USB będzie zgubić (lub nadepnięcie lub zjedzony przez psa lub spadła do białego rosyjskim) prędzej lub później.

— Mike Baranczak

1

@MikeBaranczak: Dobra uwaga - ale wszystko, co znajduje się na dysku USB, powinno być regularnie archiwizowane, niezależnie od tego, czy jest to repozytorium CVS, czy nie.

— Keith Thompson

w systemie rozproszonym każdy klient ma już pełną kopię repozytorium. Nie ma więc powodu, aby istniała osobna procedura tworzenia kopii zapasowej.

— Mike Baranczak

1

@MikeBaranczak: Jasne, to dobry powód, aby użyć DCVS. Chodzi mi o to, że wybór DCVS zamiast systemu scentralizowanego nie zależy od tego, czy używasz napędu kciukiem, czy nie.

— Keith Thompson

0

Jako dodatek do innych odpowiedzi:

Podczas gdy DVCS bardzo dobrze pasuje do tego problemu, możesz technicznie użyć Subversion, jeśli czujesz się z tym lepiej. Subversion może używać katalogu lokalnego zamiast serwera centralnego. Możesz po prostu umieścić to na pendrivie i używać.

Wadą, w porównaniu do DVCS, jest to, że możesz pracować tylko z Subversion (tj. Zatwierdzać, przeglądać logi itp.), Gdy napęd pendrive jest podłączony. Ponadto, zawsze musi to być ten sam napęd pendrive (lub przynajmniej -to-date copy), ponieważ w Subversion nie powinieneś używać więcej niż jednego repozytorium (jest to część niepoddana dystrybucji). Więc jeśli kiedykolwiek zapomnisz swojego napędu kciuka, nie możesz go używać, w przeciwieństwie do Git lub Mercurial.

Uwaga:

Jak wyjaśniono powyżej i w komentarzach, DVCS naprawdę lepiej pasuje do twojego problemu. Wspomniałem tylko o Subversion ze względu na kompletność, a jeśli masz jakiś szczególny powód, aby używać Subversion.

— Śleske
źródło

1

Podobnie jak w przypadku odpowiedzi Keitha , problem z VCS w katalogu lokalnym polega na tym, że jest to pojedynczy punkt awarii. Ponadto, jeśli przejdziesz z komputera A na komputer B, ale pozostawisz napęd kciuka podłączony do maszyny A, wtedy znacznie mniej prawdopodobne jest, że będziesz się przejmować, jeśli używasz DVCS (zawsze możesz scalić lokalne zmiany później), podczas gdy z VCS , musisz wrócić do maszyny A, zdobyć napęd i wrócić do maszyny B, zanim będziesz mógł kontynuować.

— Mark Booth,

@MarkBooth: Nie opowiadam się za tym rozwiązaniem, chciałem tylko wskazać, że istnieje, ze względu na kompletność oraz w przypadku, gdy OP ma jakieś specjalne preferencje dla Subversion. Zredagowałem moją odpowiedź, aby to wyjaśnić.

— śleske,

Dzięki @sleske, zgadzam się, że preferencja svn(lub rzeczywiście Cv) może przemawiać za korzystaniem z tego rozwiązania, ale w interesie pełnego ujawnienia należy również wspomnieć o wadach tego podejścia. Zmodyfikuj punkty z mojego komentarza do swojej odpowiedzi. Jeśli to zrobisz, chętnie wyczyszczę (skasuję) moje komentarze. * 8 ')

— Mark Booth

Nie jestem pewien, co dodaje ta odpowiedź, której jeszcze nie powiedziałem.

— Keith Thompson

1

@KeithThompson: Dodaje informację, że SVN może używać katalogu lokalnego zamiast serwera centralnego. Wyjaśnia to dokumentacja SVN, ale ponieważ większość ludzi używa SVN za pośrednictwem centralnego serwera, może nie być oczywiste, że SVN nie wymaga serwera.

— śleske,