DVCS работает на удаленном сервере

Question

Мое рабочее место рассматривает возможность перехода на современную (D) VCS, к которой я стремлюсь.

Мой начальник находится в идее, и текущий рабочий процесс будет иметь централизованное хранилище, где всемогут фиксировать / объединять свои изменения, когда задача выполнена. Во время работы над задачей каждый разработчик может иметь свою собственную ветвь для работы и выполнения.

Проблема в том, что он не очень любит идею о том, чтолюди имеют код на своих рабочих станциях только до тех пор, пока изменения не будут переданы в общий репозиторий.Это из-за сбоев диска и т. Д.

Он хотел бы видеть, что у каждого есть своя ветвь на сервере, которая будет автоматически обновляться при фиксации на локальной рабочей станции.

Поддерживает ли какая-либо DVCS это простым в настройке способом?

Обратите внимание, что я лично считаю, что для каждого разработчика вполне приемлемо взять на себя ответственность за резервное копирование своего кода, например, просто отправив свои изменения в приватветка на удаленном сервере.Это можно сделать вручную или автоматически с помощью скрипта cron.

Answer 1

Только для фактора «мы тоже»: это возможно в mercurial, как в bzr и git.Просто используйте зацепку фиксации, которая подталкивает к более централизованному репо, когда доступно.Примерно так:

[hooks]
commit = hg push ssh://path/to/individual/developer/repo

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

• убедитесь, что у них есть репо, к которому они могут подтолкнуть, что не имеет никаких ожиданий по поводу компиляции / прохождения тестов - репо с контрольной точкой, еслиВы
• упростите для них настройку непрерывной интеграции репозиториев по своему выбору на центральном сервере - если им будет три щелчка, чтобы начать сборку при изменении для своего личноговетвления затем они будут нажимать после каждого изменения, просто чтобы увидеть, как запускается набор тестов
• не позорьте их за наличие истории ветвлений - хорошее использование DVCS включает в себя много циклов вытягивания / слияния / проталкивания.Если вы заставите их использовать rebase или свернуть, чтобы превратить 30 наборов изменений с 15 слияниями в один набор изменений для каждой функции / ошибки, тогда они будут заинтересованы в том, чтобы держать объект локально до тех пор, пока он не будет готов вытащить / объединить / протолкнуть всю вещь одновременно
• запускать некоторые неосуждающие метрики в публичном месте.Ничто так не драконово и не глупо, как ранжирование разработчиков по строкам кода, но что-то, что можно заметить, будь то совокупный RSS-канал из всех RSS-репозиториев или псевдоним commits @ email, который быстро получает "X отправил набор изменений Y в репозиторий Z".«сообщение всякий раз, когда кто-то толкает.Это хорошо, потому что людям всегда нравится немного солнечного света в их сверхурочные часы, и "толчок" в конце сеанса это дает.

Answer 2

Похоже, ваш начальник работает над возможностью иметь DVCS, но также хочет иметь централизованный SCM, работая "в офисе".

Это правильно, тогда почему бы вам не взятьпосмотрите на пластик СКМ?Это именно то, что мы делаем: вы можете распределяться или (более «дружелюбно к предприятиям») работать централизованно (или их комбинация. И все же все дело в ветвлении.

Взгляните на эти двастатьи:

http://codicesoftware.blogspot.com/2010/08/branch-per-task-workflow-explained.html http://codicesoftware.blogspot.com/2010/03/distributed-development-for-windows.html

А может и здесь: http://www.plasticscm.com/features/task-driven-development.aspx

Answer 3

Это звучит довольно похоже на настройку, которую мы имеем в настоящее время с Bazaar, но я думаю, что ее можно воспроизвести в Mercurial и других, используя перехваты post-commit в Git или «push-after-commit» в Mercurial. Способ сделать это на базаре - сделать что-то вроде этого:

# Create a repository
bzr init-repo --no-trees path/to/server/project
# Create the main development branch
bzr init path/to/server/project/trunk
# Create the local working copy (which contains the complete history but is bound to the server copy of trunk)
bzr co path/to/server/project/trunk working-directory-name
# Alternative command that works the same:
bzr branch --bind path/to/server/project/trunk working-directory-name

cd working-directory-name

# Now create a branch for the user to work on
bzr switch -b new-branch
# Hack hack hack
# Commit (gets pushed to server as this is a checkout a.k.a bound-branch)
bzr ci -m "Done stuff"
# Go back to trunk to merge
bzr switch trunk
# Merge
bzr merge path/to/server/project/new-branch
# Commit the merge changes (gets pushed to server)
bzr ci -m "Merged new-branch"

Все ветки будут храниться в хранилище в / path / to / server / project. Любые коммиты в локальную рабочую копию будут автоматически отправлены на сервер. Если вы используете GUI, вы можете установить мой плагин remote-feature-branch , который автоматизирует процесс создания нового хранилища с ветвью ствола и проверки его локально (первые три команды выше).

---

Я только немного использовал Mercurial, но я полагаю, что вы могли бы сделать это, если бы у вас была ветвь на сервере, чтобы ветвить ее локально, и отредактировать файл .hgrc, включив в него:

[hooks]
commit.autopush = hg push

У всех пользователей будет локальная копия, которая содержит все ветви в этом случае, тогда как на базаре локальная копия будет иметь только историю ветви, с которой они работали. Немного разные реализации, но функционально, я думаю, почти одинаковые.

Answer 4

Вы можете подготовить ловушку после фиксации (см. .git/hooks/post-commit.sample в вашем локальном репозитории) для автоматической отправки текущей ветки на сервер.

Если вы сделаете это, я думаюИмена ветвей на общем сервере должны начинаться с имени разработчика, чтобы избежать конфликтов имен.