Рабочий процесс для поддержки локальных репозиториев удаленных репозиториев Subversion

Question

Я понимаю важность использования контроля версий и пытаюсь узнать как можно больше, чтобы настроить SVN для проектов веб-разработки нашей компании. Прямо сейчас мы все работаем с одного экземпляра разработчика, и это в лучшем случае грязно.

Многие из наших пользователей работают удаленно, а сервер dev находится в медленном интернет-соединении. Из того, что я прочитал, пользователям рекомендуется каждый раз запускать свои собственные репозитории SVN, чтобы отслеживать свои изменения, а затем синхронизировать их с репозиториями сервера. Каков наилучший способ сделать это?

В противном случае, лучше ли каждому пользователю иметь собственную рабочую копию репозитория сервера и работать только с этим?

Поскольку сервер находится в медленном соединении, лучше ли каждому разработчику (команде из 7 человек) иметь свою рабочую копию на сервере dev или локально на своем компьютере?

Я также смотрю на GIT в Windows, но SVN очень зрелый и имеет плагины для Visual Studio, которые мы можем использовать.

Answer 1

Если вы используете SVN, я бы также использовал SVK, чтобы предложить отключенный доступ к вашему хранилищу. Но в случае, который вы описываете, я бы также предложил git или mercurial как лучший вариант. Оба поддерживают отправку наборов патчей на удаленную сторону для интеграции в «главное» дерево, если вы этого хотите.

Answer 2

... git evangelist, отправляющийся на службу! ;)

Как отмечает sbi, это звучит как среда, лучше всего подходящая для распределенной VCS (например, git ). Однако , как вы могли заметить, git на Windows еще не очень развит. Тем не менее, это происходит быстро. В вашем случае может быть интересно узнать, что интеграция с Visual Studio пока не очень приятна. Существует GitExtensions , который интегрируется с VS, но это не так блестяще. В качестве альтернативы есть TortoiseGit .

Существуют и другие распределенные VCS, которые могут быть интересны, например, Mercurial или Bazaar , которые, возможно, созрели немного больше. Хотя не уверен насчет этого. Не использовал их целую вечность.

Я бы не пошел дальше, чтобы принять SVN в качестве распределенной VCS. Он не разработан с учетом этого варианта использования, поэтому его реализация будет затруднена. Даже если VS-Integration это хорошо. Слияние станет проблематичным.

С другой стороны, VS-Integration не так важен. Лучше иметь не очень хорошую интеграцию, чем вообще не иметь контроля версий. И мне еще предстоит увидеть инструмент, который отлично справляется с 1026 *. Поэтому я бы рекомендовал изучить действительно распределенные VCS. Поначалу концепция может показаться пугающей / запутанной, но она того стоит.

edit: Я сказал, что git не очень зрелый в Windows. Это не так уж и плохо. Он не так совершенен, как в Linux, но, тем не менее, очень полезен !

Answer 3

Конечно, GIT полностью соответствует вашим требованиям. Это быстро, вы просто сливаетесь с GIT.

Хотя для меня, если бы Вы придерживались SVN:

• рассмотрим использование веток. Тогда основной ствол хранилища останется чистым. Единственная проблема - это слияние. Но это ИМХО лучше, чем локальное отслеживание (если вы не используете git).

• Отметьте только важные рабочие изменения в конце дня.

• планируйте свою работу вперед, планируйте задачи, назначайте задачи соответствующим людям, тогда у вас будет меньше времени на слияние и время разработки.

Answer 4

Поскольку ваша команда небольшая (7 человек), SVN прекрасно работает и имеет богатый набор (Windows) инструментов, которые являются зрелыми и простыми в использовании.

Мы используем VisualSVN (http://www.visualsvn.com/) в качестве нашего сервера. Его легко настроить, и он бесплатный. Клиенты, предлагаемые одной и той же компанией, поддерживают интеграцию с Visual Studio и будут иметь небольшую стоимость лицензирования для ваша маленькая команда.

Так как Git очень модный и популярный, я ожидаю большого количества отрицательных голосов, но он по-прежнему в основном инструмент Linux. TortoiseGit пока не очень хорошо работает, и дело в том, что это VCS, созданная разработчиком ОС - это все равно, что использовать решение, разработанное MS.

Mertorial TotoiseHg все еще намного лучше в Windows, чем его эквивалент Git (если судить по опыту).

Оба решения DVCS добавят дополнительное время для обучения вашей команды, так как вам нужно будет разработать процесс, которому должны следовать все. Также ни один из них не имеет действительно жизнеспособных итераций Visual Studio.

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

Наконец, я не уверен, что какое-либо из решений (D) VCS имеет большое преимущество перед другими при работе с медленной связью.

Answer 5

Вы знали, что это придет: я пойду с GIT.

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

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

Проверьте tortoiseGit и будьте готовы к обучению. Однако, в конце концов, это будет гораздо ближе к тому, что вы хотите.

Если вы используете SVN, я бы придерживался единственного репозитория, если только вы не используете расширение типа WANdisco . Вы можете использовать svnsync , но ознакомьтесь с ограничениями (репозитории только для чтения и т. Д.).

Answer 6

Ваш второй абзац похож на софтбольное поле для толпы мерзавцев. Git определенно мой предложенный выбор. Честно говоря, любая Распределенная Revision Control System (например, Mercurial) тоже подойдет, но git - это только мой (и многие другие разработчики) молоток в наборе инструментов.

Вам не нужно проходить через головные боли при управлении отдельным репозиторием Subversion для каждого разработчика; DRCS имеет эту особенность. Каждый разработчик клонирует главный репозиторий, выполняет работу и фиксирует / ветвится / и т. д. столько, сколько они хотят на своей локальной машине. Затем, когда они будут готовы продвигать код для просмотра другими, они отправляют все свои ревизии / ветки обратно в ваш внутренний репозиторий.

Честно говоря, я использовал git всего несколько месяцев, но теперь я никогда не вернусь к подрывной деятельности. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *.