Однопользовательская система управления версиями для нескольких компьютеров
У меня есть два компьютера (рабочий и домашний), и я хочу настроить систему контроля версий для исходного кода и документов TeX. Соавторов нет (т.е. однопользовательский / редактор). Большинство исходных файлов написаны с использованием редактора vi. Я хотел бы, чтобы версия источника / документа была доступна на обоих компьютерах.
Существует ли конкретная структура управления версиями (централизованная или распределенная), которая лучше подходит для однопользовательских и многопользовательских нужд? Например, я мог бы настроить один компьютер в качестве сервера, а другой - в качестве клиента, или альтернативно рассматривать оба компьютера как равноправные.
Кроме того, я хочу иметь возможность легко синхронизировать два компьютера, и я не знаю, если rsync было бы лучше для этого, или если эта функция лучше выполняется системой контроля версий?
3 ответа
Отказ от ответственности: мое предложение предполагает, что у вас есть подключение к Интернету как дома, так и на работе.
У меня почти такая же ситуация. Я управляю своим исходным кодом и документами, используя git на бесплатной учетной записи UbuntuOne. Всякий раз, когда мне нужно что-то изменить / добавить, я просто clone требуемый репозиторий (например, "Project X docs") и выполняйте работу локально либо на рабочем, либо на домашнем компьютере, либо на обоих, а затем вносите изменения. В нескольких случаях я даже делился репозиторием или двумя с коллегами для просмотра / редактирования файлов. git не подводил меня до сих пор с его превосходными средствами слияния.
НТН,
Система синхронизации и система контроля версий - это две разные вещи, отвечающие различным потребностям.
Как программист, вы хотите иметь контроль над своим кодом. Если вам не нужно синхронизировать что-либо еще, не беспокойтесь о синхронизации, поскольку она, очевидно, не обеспечит управление версиями (которое само может использоваться для синхронизации). В этом случае вы можете просто перейти на контроль версий. И если вам нужно синхронизировать другие вещи, вам все равно понадобится контроль версий. Поэтому я настоятельно рекомендую сначала настроить некоторые версии кода, а затем подумать о синхронизации. Код без контроля версий... совершенно неверный.
Теперь, если вы используете централизованное управление версиями, вам придется выбрать сервер. Затем вам придется сделать резервную копию этого сервера, потому что у вас будет только текущая версия кода на вашем другом компьютере. Вот почему я бы посоветовал вам поискать распределенный контроль версий. Git или Hg (Mercurial) подойдет. Таким образом, у вас есть полная история версий кода на обоих компьютерах. Если кто-то умирает, вы ничего не теряете (по крайней мере, кода!).
НО, если вы хотите синхронизировать ВСЕГДА, использование централизованной системы контроля версий не так уж и плохо, поскольку вы можете просто синхронизировать ее файлы с другим компьютером. Таким образом, у вас есть централизованное + автоматическое резервное копирование. Все еще распределенный будет иметь больше гибкости, когда вы передумаете.
Это ваш вызов. Я предлагаю распределенную систему (Git или Hg... они очень похожи, и у них есть системы хеширования, которые усложняют повреждение их кодовых баз), а затем посмотрите, что вы делаете с синхронизацией, если она вам действительно нужна.
Я думаю, что вопрос в этом посте уникален.
Нет на самом деле, один пользователь один места | расположение много-много пользователей или любая промежуточная ситуация не вносит больших изменений в используемые СКМ
- Если оба рабочих места подключены к Интернету и всегда доступны для повторного подключения, вы можете в любое время выбрать любую *VCS (даже CVCS) и выполнить обновление из репо (для DVCS - переключение из последнего использованного репо в старое) без использования 3-го посредника.
- Если хосты не всегда в сети, используйте (опять же) любой SCM и сохраняйте работу на любом SCM-хостинге, поддержка которого выбрана вами SCM
- Если хост находится в автономном режиме, вы можете вспомнить "Omnia mea mecum porto" и иметь, например, Fossil SCM (переносной, одиночный exe, кроссплатформенный) и репозиторий на флэш-накопителе.