Подвижный рычаг, не выполняющийся правильно

Вам необходимо иметь его в hgrc удаленного репозитория . Похоже, он находится в вашем локальном репо.

Изменить: Это также зависит от того, как вы продвигаетесь. Некоторые методы не вызывают хуки с правой стороны. (ssh, я думаю, HTTP, файловая система , а не )

Edit2: Что, если вы нажмете «локально» на компьютере удаленного репо. У вас могут быть разные пользователи / разрешения между веб-сервером и файлом hgrc. (См. [Server] и доверенные директивы для hgrc.)

Попробуйте включить отладку ловушки , чтобы понять, почему она не работает.

Вероятно, проблема с разрешениями или что-то в этом роде.

Прежде всего, я хочу исправить несколько замечаний выше.

• Перехватчики вызываются также при передаче файловой системы через файловую систему.
• Нет необходимости сохранять перехватчик в репо, с которым вы хотите, чтобы они работали. Вы также можете написать тот же крючок, что и в вашем вопросе, на стороне пользователя. Вы должны изменить событие с группы изменений на исходящее, а также указать URL-адрес удаленного репо с помощью переключателя -R. Затем, если проталкивающий пользователь имеет достаточные привилегии в удаленном репо, ловушка будет успешно выполнена.

.hg / hgrc

[hooks]
outgoing = hg update -R $HG_URL

Теперь перейдем к вашей проблеме .... Я предлагаю создать хуки prechangegroup и changegroup и распечатать некоторые отладочные данные. .

.hg / hgrc

[hooks]
prechangegroup = echo "Remote repo is at `hg tip -q`"
                 echo "Remote repo wdir is at `hg parents -q`"
changegroup    = echo "Updating.... `hg update -v`"
                 echo "Remote repo is at `hg tip -q`"
                 echo "Remote repo wdir is at `hg parents -q`"

А также нажмите с помощью переключателя -v, чтобы вы могли знать, какая ловушка запущена. Если вы все еще не можете понять, опубликуйте результат. Я мог бы помочь.

Как говорили другие, нет единого стандарта для именования файлов в окнах.

Для нашей полной базы продуктов, которая охватывает 100's exes, dlls и статических libs, мы успешно использовали следующее в течение многих лет, и это спасло много путаницы. В основном это смешение нескольких методов, которые я видел использованными на протяжении многих лет.

В двух словах все наши файлы имеют префикс и суффикс (не включая само расширение). Все они начинаются с «ома» (на основе названия нашей компании), а затем имеют комбинацию из 1 или 2 символов, которая примерно идентифицирует область кода.

Суффикс объясняет тип их встроенного файла и включает в себя до трех букв, используемых в комбинации, в зависимости от сборки, которая включает Юникод, Статик, Отладка (сборки DLL по умолчанию и не имеют явного идентификатора суффикса). Когда мы начали эту систему Юникод был не так распространен и мы должны были поддерживать и Юникод и не Юникод сборки (до Windows 2000 os), теперь все исключительно построен Юникод, но мы по-прежнему использовать одну и ту же номенклатуру.

Так типичный .lib «набор» файлов может выглядеть как

omfThreadud.lib (Unicode/Debug/Dll)
omfThreadusd.lib (Unicode/Static/Debug)
omfThreadu.lib (Unicode/Release/Dll)
omfThreadus.lib (Unicode/static)

Все файлы встроены в общую папку bin, что устраняет множество проблем dll-hell для разработчиков, а также упрощает настройку параметров настройки компилятора/компоновщика - все они указывают на одно и то же местоположение, используя относительные пути, и нет необходимости в ручном (или автоматическом) копировании библиотек, необходимых проекту. Наличие этих суффиксов также устраняет любые путаницу в отношении того, какой тип файла у вас может быть, и гарантирует, что у вас не может быть смешанного сценария, когда вы помещаете DLL отладки в комплект выпуска или наоборот. Все бывшие также используют аналогичный суффикс (Unicode/Debug) и встраиваются в одну папку bin.

Существует также одна папка «include», каждая библиотека имеет один файл заголовка в папке «include», который совпадает с именем библиотеки/dll (например, omfthread.h) Этот файл сам по себе # включает в себя все другие предметы, предоставляемые этой библиотекой. Это сохраняет свою простоту, если вы хотите функциональность, которая находится в foo.dll вы просто # include «foo.h»; наши библиотеки сильно сегментированы по областям функциональности - фактически у нас нет никаких «швейцарско-армейских ножей», поэтому, включая всю функциональность библиотек, имеет смысл. (Каждый из этих заголовков также включает в себя другие необходимые заголовки, будь то наши внутренние библиотеки или другие SDK поставщика)

Каждый из них включает в себя файлы, внутри которых используются макросы, которые используют # pramga's для добавления соответствующего имени библиотеки к строке компоновщика, поэтому отдельные проекты не должны быть связаны с этим. Большинство наших библиотек могут быть построены статически или как DLL и # define OM_LINK_STATIC (если определено) используется, чтобы определить, какой отдельный проект хочет (мы обычно используем DLL, но в некоторых случаях статические библиотеки, встроенные в .exe имеют больше смысла для развертывания или других причин)

#if defined(OM_LINK_STATIC)
 #pragma comment (lib, OMLIBNAMESTATIC("OMFTHREAD"))
#else
 #pragma comment (lib, OMLIBNAME("OMFTHREAD"))
#endif

Эти макросы (OMLIBNAMESTATIC & OMLIBNAME)используется _DEBUG определения типа построения и создания соответствующего имени библиотеки для добавления к строке компоновщика.

Мы используем общее определение в статических & dll-версиях библиотеки, чтобы управлять правильным экспортом класса/функций в dll-сборках. Каждый класс или функция, экспортированные из библиотеки, декорированы этим макросом (имя которого соответствует базовому имени библиотеки, хотя это в значительной степени не важно)

class OMUTHREAD_DECLARE CThread : public CThreadBase

В DLL-версии параметров проекта мы определяем OMFTHREAD_DECLARE=__declspec (dllexport), в статической библиотечной версии библиотеки мы определяем OMFTHREAD_DECLARE как пустой .

В файле заголовка библиотек мы определяем его на основе того, как клиент пытается связать с ним

#if defined(OM_LINK_STATIC)
 #define OMFTHREAD_DECLARE
#else
 #define OMFTHREAD_DECLARE __declspec(dllimport)
#endif

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

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

Вся таблица - это один «организм». Были внесены некоторые изменения и оговорки в общий подход к генетическим алгоритмам:

• Правила были сделаны для «незаконных таблиц»: два класса в одном классе, один учитель, обучающий две группы одновременно и т.д. Эти мутации были признаны смертельными немедленно, и новый «организм» был проращен вместо «умершего» немедленно. Начальный был сгенерирован серией случайных попыток получить легальный (если бессмысленный). Смертельная мутация не была засчитана в счет мутаций в итерации.

• Мутации «Exchange» были гораздо более распространены, чем мутации «Modify». Изменения были только между частями гена, которые имели смысл - никакой замены учителя классом.

• Небольшие бонусы были назначены за объединение определенных 2 часов вместе, за назначение одного и того же общего класса в последовательность для одной и той же группы, за поддержание рабочего времени учителя и непрерывной нагрузки на класс. Умеренные бонусы назначались за предоставление правильных аудиторий для данного предмета, поддержание часов занятий в рамках облигаций (утром или днем) и т. Д. Большие бонусы были за назначение правильного количества данного предмета, заданную рабочую нагрузку для учителя и т. Д.

• Учителя могли создавать свои графики рабочей нагрузки «хочу работать тогда», «хорошо работать тогда», «не любит работать тогда», «не может работать тогда», с назначенными правильными весами. Целых 24 часа были законными рабочими часами, за исключением того, что ночное время было очень нежелательным.

• Функция веса... О да. Весовой функцией было огромное, чудовищное произведение (как в умножении) весов, присвоенных выбранным признакам и свойствам. Он был чрезвычайно крутым, одно свойство легко могло изменить его на порядок вверх или вниз - и в одном организме были сотни или тысячи свойств. Это привело к абсолютно огромным числам в качестве весов, и как прямой результат,для выполнения вычислений необходимо использовать библиотеку bignum (gmp). Для небольшого теста некоторых групп 10, 10 учителей и 10 классных комнат, начальный набор начинался с запоминания 10 ^ -200сетинга и заканчивался 10 ^ + 300сетингом. Это было совершенно неэффективно, когда было более ровным. Кроме того, с большими «школами» эти ценности значительно расширились.

• С точки зрения времени вычисления, было мало различий между небольшим населением (100) в течение длительного времени и большим населением (10 000 +) в течение меньшего числа поколений. Вычисления за то же время дали примерно одинаковое качество.

• Расчет (на некотором 1GHz CPU) займет около 1 ч, чтобы стабилизироваться вблизи 10 ^ + 300, генерируя графики, которые выглядели довольно неплохо, для указанного тестового случая 10x10x10.

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

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

Ну, пройдя те же шаги разочарования, что и Марк W некоторое время назад, я наконец нашел решение проблемы, по крайней мере, когда удаленное обслуживание выполняется с помощью скрипта hgwebdir WSGI.

Я выяснил, что при использовании такого типа удаленного push через HTTP или HTTPS Mercurial просто игнорирует все, что вы записываете в файл .hg/hgrc или ваш репозиторий. Однако ввод крючка в конфигурационном элементе hgwebdir делает этот трюк.

Поэтому, если итоговая строка в сценарии hgwebdir.wsgi подобна

application = hgwebdir('hgweb.config')

, раздел [hooks] config должен перейти в упомянутый hgweb.config .

Один недостаток заключается в том, что эти крючки выполняются для каждого репозитория , указанного в разделе [paths] этого конфигурационного элемента. Несмотря на то, что HG предлагает другую WSGI-совместимую функцию (hgweb вместо hgwebdir) для обслуживания только одного репозитория, эта функция, похоже, не поддерживает никаких зацепов (как и не имеет никакой конфигурации). Это, однако, можно обойти, используя hgwebdir, как описано выше, и имея Apache RewriteRule, отображающий все в желаемый подкаталог. Это работает для меня:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/reponame
RewriteRule ^(.*)$ reponame/$2 [QSA]

Развлекайтесь, используя удаленные крючки по HTTP: D