Контроль версий на основе портативного хранилища?

9

Я разрабатываю личные проекты на двух машинах без использования общего сервера или сетевого соединения между ними.

Поддерживают ли какие-либо распространенные системы контроля версий надежное использование портативного хранилища (например, USB-устройства флэш-памяти) в качестве общего хранилища?

version-control

— billpg
источник

Почему вы хотите / должны использовать портативное хранилище?

— Бернард

Перемещать код между двумя машинами так же, как обычная система контроля версий с общим сервером. (У меня нет общего сервера.)

— billpg

Я использовал набор ртутных репозиториев на флэш-накопителе USB для обновления производственных инструментов на заводе, и это работало действительно хорошо. Вы даже могли видеть, когда технические специалисты на сайте изменяли код на локальном компьютере, пока вас не было, и объединяли (или отклоняли) свои изменения перед синхронизацией изменений на флэш-накопителе.

— Марк Бут

Здесь уже сказано, что SVN поддерживает локальное хранилище, и вы можете использовать USB. Но я предпочитаю хранить эту БД в моей личной папке DropBox;) Вы также можете использовать множество бесплатных сервисов (например, сборка или tfs.visualstudio.com)

— Павел Воронин,

31

Используйте DVCS, такой как Git или Mercurial .

Распределенные системы контроля версий не имеют общего центрального сервера.

С DVCS каждая копия репозитория содержит полную историю - все. Это означает, что при использовании на USB-ключе любые внесенные вами изменения вносятся в репозиторий на USB-ключе и при перемещении между компьютерами сохраняют эту историю.

— Одед
источник

9

А если бы вы использовали github, вам даже не пришлось бы носить с собой USB-накопитель

— CamelBlues

Спасибо. Можно ли настроить переносное хранилище в качестве хранилища?

— billpg

@billpg - Да. Он просто живет в структуре каталогов.

— Одд

@CamelBlues или bitbucket или kilnhg или, возможно, различные другие, которые могут или не могут быть подходящими ...

— Murph

3

У меня есть мои основные личные репозитории Mercurial на DropBox. Прекрасно работает и автоматически реализует резервное копирование (поскольку DropBox вряд ли исчезнет в то же время, когда я потеряю все мои компьютеры).

— Дэвид Торнли

7

Помимо GIT, Mercurial и др., Предложенных выше, также обратите внимание на Fossil - у него есть преимущества, заключающиеся в том, что двоичные файлы времени выполнения являются небольшими (1Meg или около того для Windows и Linux), переносимы и не требуют установки. Поэтому, в отличие от других (насколько мне известно), его можно поместить на устройство хранения и запустить на любой машине, к которой подключено хранилище, без предварительной установки приложения на машину. Он включает в себя Wiki и систему отслеживания изменений / дефектов с репо. Он также имеет встроенный графический интерфейс.

Я не использовал его всерьез (я в основном использую GIT), но был впечатлен его легким подходом, а включение Wiki и дефектоскопа делает его идеальным для небольших проектов. Моя единственная обеспокоенность заключалась в том, что некоторые из более мощных функций GIT могут быть невозможны, и в отличие от GIT, сообщество пользователей не настолько велико, что легко найти ответы на вопросы.

— mattnz
источник

Хотя Git принимает заповедь Unix, чтобы делать что-то одно и делать это серьезно, вы можете использовать эти функции в Git с помощью таких расширений, как ticgit (система тикетов) и gollum (вики на основе репо).

— Джейсон Льюис

@Jason Lewis: Вы правы, и, поскольку это открытый исходный код, вы можете в любом случае просто изменить его, чтобы он соответствовал вашим требованиям, поэтому GIT (или любой другой инструмент) может быть всем для всех (кто может быть обеспокоен, имеет свободное время и ресурсы). загрузить, установить и отладить все «плагины». Все, что я говорил, - это решение «Просто работает из коробки», стоит рассмотреть Fossil.

— mattnz

1

Использование DCVS, вероятно, хорошая идея, но это не единственный вариант.

У меня есть небольшой репозиторий CVS на флэш-накопителе USB. Когда я хочу получить к нему доступ, мне просто нужно использовать cvs -d <path>или указать $CVSROOTпуть к корню хранилища (что, конечно, требует, чтобы в системе был установлен флэш-накопитель).

Если вы уже привыкли использовать CVS, это должно быть работоспособно. То же самое должно относиться к SVN. Это просто означает, что ваш центральный репозиторий находится на флэш-накопителе и не всегда виден.

Есть аргументы для использования DCVS, а не CVS в целом. Я не думаю, что на эти аргументы особенно влияет то, находится ли центральное хранилище на флэш-накопителе или где-то еще. Например, вы можете также легко создать git-репозиторий на флэш-накопителе.

— Кит Томпсон
источник

1

Я обычно не большой поклонник DVCS, но я думаю, что DVCS будет лучше в этом случае. Проблема с нераспределенной VCS заключается в том, что репо является единственной точкой отказа. Если он находится в дата-центре с климат-контролем и регулярно получает резервные копии, это не имеет большого значения - но что-то вроде большого пальца будет потеряно (или наступит, или съедено собакой, или упадет в белого русского) раньше или позже.

— Майк Баранчак

1

@MikeBaranczak: Хороший вопрос - но все, что находится на флэш-накопителе, должно регулярно создаваться резервные копии, будь то хранилище CVS или нет.

— Кит Томпсон

в распределенной системе каждый клиент уже имеет полную копию репо. Так что нет никакой причины для отдельной процедуры «резервного копирования».

— Майк Баранчак

1

@MikeBaranczak: Конечно, это хорошая причина использовать DCVS. Я хочу сказать, что выбор DCVS или централизованной системы не зависит от того, используете ли вы флеш-накопитель или нет.

— Кит Томпсон

0

В дополнение к другим ответам:

Хотя DVCS очень хорошо подходит для этой проблемы, технически вы также можете использовать Subversion, если вам удобнее. Subversion может использовать локальный каталог вместо центрального сервера. Вы можете просто положить это на флэш-накопитель и использовать его.

Недостаток, по сравнению с DVCS, заключается в том, что вы можете работать только с Subversion (т. Е. Зафиксировать, просматривать журналы и т. Д.), Когда подключен флэш-накопитель. Кроме того, он всегда должен быть одним и тем же флэш-накопителем (или, по крайней мере, -to-date copy), потому что с Subversion вы не должны использовать более одного репозитория (это нераспределенная часть). Поэтому, если вы когда-нибудь забудете свой флэш-накопитель, вы не сможете его использовать, в отличие от Git или Mercurial.

Замечания:

Как объяснено выше и в комментариях, DVCS действительно лучше подходит для вашей проблемы. Я упоминал Subversion только для полноты картины, и в случае, если у вас есть особые причины использовать Subversion.

— sleske
источник

1

Как и в ответе Кейта , проблема с VCS в локальном каталоге заключается в том, что это единственная точка отказа. Кроме того, если вы переходите с компьютера A на компьютер B, но оставляете флэш-накопитель подключенным к компьютеру A, то вам гораздо меньше будет дела до использования DVCS (вы всегда можете объединить локальные изменения позже), тогда как с VCS , вам придется вернуться к механизму А, получить диск и вернуться к машине Б, прежде чем вы сможете продолжить.

— Марк Бут

@MarkBooth: я не защищаю это решение, я просто хочу указать, что оно существует, для полноты картины, и в случае, если у OP есть какие-то особые предпочтения для Subversion. Я отредактировал свой ответ, чтобы прояснить это.

— слеске

Благодаря @sleske, я согласен с тем, что предпочтение svn(или даже Cvs) может иметь значение в пользу использования этого решения, но в интересах полного раскрытия следует также упомянуть недостатки этого подхода. Не стесняйтесь редактировать пункты из моего комментария в ваш ответ. Если вы это сделаете, я был бы рад очистить (удалить) мои комментарии. * 8 ')

— Марк Бут

Я не уверен, что этот ответ добавляет, что я еще не сказал в моем.

— Кит Томпсон

1

@KeithThompson: добавляет информацию о том, что SVN может использовать локальный каталог вместо центрального сервера. Это объясняется в документации по SVN, но, поскольку большинство людей используют SVN через центральный сервер, может быть неочевидно, что SVN не требует сервера.

— слеске