Как настроить Mercurial для развертывания только папки веб-сайта

У меня есть веб-сайт, который я хочу развернуть в клиентских средах DEV и UAT, этот сайт является частью ртутного репозитория - он находится в папке «Веб-сайт» на том же уровне, что и папка .hg. Я знаю, что могу протолкнуть весь репозиторий, но предпочитаю нажимать только папку веб-сайта, чтобы у клиента не было других файлов и папок.

Репо выглядит так:

  • Project root
    • .hg
    • База данных (это используется в системе управления исходным кодом SQL)
    • Документация (Все спецификации, PDF-файлы, иллюстрации и т. Д.)
    • Lib (сторонние библиотеки DLL до Nuget)
    • пакеты (материалы Nuget)
    • Веб-сайт (это единственная область, которую я хочу развернуть)
    • .hgignore
    • Project.sln

Изменить: серверы клиентов не подключены напрямую к Интернету, мой доступ к ним осуществляется через VPN, а затем RDP. В настоящее время для развертывания любых изменений мне нужно заархивировать сайт, поместить его на общий ftp-сервер и подождать до 3 дней, пока файлы будут скопированы на серверы. Правила настроены, поэтому я могу использовать Mercurial через это соединение.

Изменить 2. Мне удалось создать вложенное репо из папки веб-сайта, забыв папку веб-сайта и все ее содержимое, зафиксировав изменение, затем вернув файлы, создав репо и повторив файл .hgsub. Локально это работает для меня, я могу клонировать из репозитория веб-сайта, не получая никаких дополнительных папок. Однако мне не удалось использовать эту версию репо, даже если я повторю процесс на нашем сервере репо. Когда я пытаюсь клонировать размещенную версию до моей локальной рабочей копии, я получаю ошибку 404, но я могу клонировать размещенную версию на хост-сервере.

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

Изменить 3. Оказалось, что у меня возникла проблема с преобразованием папки в субрепо, как описано в http://mercurial.aragost.com/kick-start/en/subrepositories/#преобразованиепапкивсубрепозиторий заключалось в том, что команда convert в версиях после 2.1.0 не работает и по-прежнему не работает в 2.3.1. После того, как я понял это и откатился к этой версии TortoiseHg, я смог преобразовать папку в субрепо, в корне репо у меня есть .hgsub, в котором указано Website = Website. Я смог работать с этим локально, зафиксировать все репо, подрепо, клонировать либо полное репо, либо подрепо (это то, что я хочу), однако я не могу заставить это работать из нашего основного репо сервер.

Я заархивировал все это и отправил по ftp на наш удаленный главный сервер репо, а затем настроил его, чтобы я мог клонировать с него. Непосредственно на сервере это работает нормально (hg clone --verbose - C: \ Repositories \ EM.), Однако, когда я пытаюсь клонировать с сервера на мою локальную машину разработки с помощью (hg clone --verbose - https://myserver.com/hg/EM/.) происходит сбой "Ошибка HTTP: 404 (не найдено ) ".

requesting all changes
adding changesets
adding manifests
adding file changes
added 628 changesets with 6002 changes to 4326 files
updating to branch default
resolving manifests
calling hook preupdate.eol: <function preupdate at 0x00000000035204A8>
getting .hgignore
getting .hgsub
getting .hgsubstate
HTTP Error: 404 (Not Found)
[command returned code 255 Fri Apr 20 10:51:23 2012]

Не знаю, в чем проблема, файлы там, так почему же 404?


person Simon Martin    schedule 22.03.2012    source источник


Ответы (4)


На мой взгляд, Mercurial не следует использовать для этой цели. Это особенно верно, если этот веб-сайт является веб-приложением, потому что у вас не должно быть библиотек DLL в Mercurial.

Вам следует взглянуть на инструмент веб-развертывания, встроенный в Visual Studio. Взгляните на это, чтобы узнать, подходит ли она для ваших целей.

Если вы не можете установить необходимые службы на конечном сервере, его можно настроить на использование FTP.

person Steve Kaye    schedule 22.03.2012
comment
Я не могу установить на целевые серверы, и у них нет прямого доступа в Интернет. В настоящее время мне нужно заархивировать файлы по ftp на сервер, а затем ждать 3 дня, пока они не будут скопированы на машину. Используя Mercurial, я могу выполнить развертывание непосредственно через имеющийся у меня vpn. Также это означает, что происходит какое-то управление версиями. - person Simon Martin; 23.03.2012

  1. Вы не можете протолкнуть часть дерева репо
  2. Если среды DEV и UAT являются неверсированными целями, вы можете использовать любой другой способ распространения контента Mercurial.
  3. Вы можете разделить веб-сайт на субрепо и сможете отправить это репо
person Lazy Badger    schedule 22.03.2012
comment
Для меня работа с субрепо - новость, но я создал субрепо из папки веб-сайта и могу продвигать его, как вы говорите. Вы знаете, как сделать так, чтобы Workbench всегда поставлял переключатель --subrepos? Я могу сделать это из командной строки, но это не мой обычный рабочий процесс - person Simon Martin; 23.03.2012
comment
@SimonMartin - грязный хак (TBT!), Но - вы можете создавать псевдонимы в hgrc репо, переопределяя необходимые команды под тем же именем, но с добавленными опциями - person Lazy Badger; 23.03.2012
comment
С субрепо я не могу вернуться к нашему центральному / главному репо. Я попытался создать копию для развертывания, клонировал мое основное локальное репо и установил там вспомогательное репо, а затем клонировал только вспомогательное репо, которое сработало. Однако я не мог затем обновить репозиторий развертывания из основного локального репозитория. Я только что отредактировал web.config для проверки, и ошибка прерывается: путь «Website \ web.config» находится внутри вложенного репо «Website». Хотя я могу создать клон развертывания, создать вспомогательное репо, а затем использовать его для отправки клиенту, это немного затянуто. Как мне избежать необходимости каждый раз создавать клон развертывания? - person Simon Martin; 23.03.2012
comment
@SimonMartin - abort: путь 'Website \ web.config' находится внутри вложенного репо 'Website' означает то же самое, что и написано - у вас все еще есть вложенное репо вместо вложенного репо. Преобразование вложенных в субрепо - прочтите MercurialWiki, как это сделать, Я не хочу и не цитирую это здесь - person Lazy Badger; 24.03.2012

Как указывали другие, вы не можете использовать для этого push. Просто выполните "rsync" со своего сервера на их. Вы даже можете автоматизировать это в хуке, когда вы отправляете в локальный репозиторий, и он автоматически развертывается на их сайте. Что-то типа:

[hooks]
changegroup.deploy = $HG update ; rsync Website account@theirserver:/path/to/docroot
person Ry4an Brase    schedule 23.03.2012
comment
Потому что вам не нужно указывать ревизию каждый раз, когда вы вызываете этот скрипт. Сама Hg говорит: Обновите рабочий каталог репозитория до указанного набора изменений. Если набор изменений не указан, обновите до конца текущей именованной ветки. - person Christoph Jüngling; 23.03.2012
comment
@ ChristophJüngling - hg export -r tip всегда. Быстрее, безопаснее - person Lazy Badger; 23.03.2012
comment
@LazyBadger Вы имели в виду hg archive вместо hg export? hg export просто дает вам подсказку, но я думал, что целью был снимок подсказки. Сначала я написал это с помощью archive, но вам нужно куда-то экспортировать это, и тогда вам нужно беспокоиться о коллизиях и блокировках. Обновление на сервере, отличном от веб-сервера, с последующей синхронизацией с веб-сервером так же безопасно. - person Ry4an Brase; 23.03.2012
comment
@ Ry4an - mea culpa, hg archive, да ... Мне больше нравится архив, потому что: без дополнительной авторизации, я могу копировать в архив только измененные файлы для одной ревизии или набора ревизий, а для огромных репозиториев это имеет значение - person Lazy Badger; 24.03.2012

У меня есть рабочее решение. Я создал командный файл, который создает исходящее репо и запускает встроенный сервер, чтобы я мог использовать его на клиентских машинах. Сначала он очищает предыдущую папку, затем клонирует мою локальную рабочую копию (есть параметр, определяющий, из какого тега следует клонировать). Затем он создает файл карты и преобразует папку Website в новую папку Website2, чтобы сохранить историю, затем удаляет исходную папку и переименовывает новую. Наконец, он раскручивает встроенный сервер.

cd c:\inetpub\wwwroot
rd /S /Q _ProjectName
hg clone -- C:\inetpub\wwwroot\ProjectName#%1 C:\inetpub\wwwroot\_ProjectName
cd c:\inetpub\wwwroot\_ProjectName
echo include Website > map.txt
echo rename Website . >> map.txt
hg --config extensions.hgext.convert= convert --filemap map.txt . Website2
cd Website2
hg update
cd ..
hg remove Website/*
hg commit -m "Removed Website"
rename Website2 Website
hg serve

Так что это некрасиво, но теперь мне просто нужно вызвать командный файл и передать тег, из которого я хочу создать исходящий веб-сайт (uat, dev и т. Д.), И дать ему минуту, чтобы создать папку моего веб-сайта с историей, что я могу использовать, чтобы вытащить или оттолкнуть. Мне не нужно вызывать hg serve, потому что я знаю имена клиентских серверов, поэтому я могу выдвинуть набор изменений, создав удаленные репозитории с псевдонимами. Но я включил этот шаг, чтобы клиентские машины могли работать. Я не полностью изучил этот вариант, поэтому не уверен, есть ли у него какое-то конкретное преимущество. Это нормально для случая, когда над проектом работаю только я, но если над этим должен работать какой-либо другой разработчик, то Uri для их локального сервера проекта, очевидно, будет другим (http: // SIMON-PC: 8000 / не будет подходить для всех), и в этом случае лучше всего будет подтолкнуть клиента.

Но при использовании этого подхода мое локальное рабочее репо не нужно менять, поэтому у меня не возникает никаких проблем при взаимодействии с нашим центральным репо, ошибки 404, упомянутые в edit3. Я сохраняю всю историю репо с процессом преобразования, поэтому в следующий раз, когда мне нужно отправить изменения, я не начинаю с версии 1 - другими словами, это не разрушает веб-сайт, и хотя я удаляю все исходящие repo (_ProjectName) каждый раз, когда я сохраняю историю, но все же могу извлекать / нажимать ТОЛЬКО каталог веб-сайта, потому что он создается каждый раз как `` автономное '' репо

person Simon Martin    schedule 26.04.2012