Как Вы избегаете, чтобы люди забыли выполнять 'нажатие мерзавца'?
__declspec( dllexport ) - класс или функция, так отмеченная, будут экспортироваться из DLL, это встроено. Если Вы создадите DLL, и Вы хотите API, необходимо будет использовать это или отдельный.DEF файл, который определяет экспорт ( MSDN). Это удобно, потому что это сохраняет определение в одном месте, но.DEF файл предоставляет больше возможностей.
__declspec( dllimport ) - класс или функция, так отмеченная, будут импортированы из DLL. Это на самом деле не требуется - Вам нужна библиотека импорта так или иначе для создания компоновщика счастливым. Но, когда правильно отмечено с dllimport, у компилятора и компоновщика есть достаточно информации для оптимизации вызова; без него Вы получаете нормальное статическое подключение к интерфейсной функции в библиотеке импорта, которая добавляет ненужную косвенность. ONT1 ONT2
4 ответа
Я согласен с тем, что в идеале вы можете исправить это, просто пытаясь дать много напоминаний. Несколько разных мыслей:
Все, что укрепляет идею распределенного контроля версий, поможет людям думать об этом более естественно. Например, я предпочитаю рабочий процесс, который включает в себя использование веток локальных тем и фиксацию изменений / перебазирования до тех пор, пока они не станут именно такими, как я хочу. Если вы научите, как это делать, станет очевидно, что это делается в вашей сфере. По мере того, как разработчики узнают, что их репозиторий отличается от центрального репозитория, вспоминать о проталкивании станет намного проще.
Если вы находитесь в своей основной ветке (или любой другой ветке, которая отслеживает ветку в источнике),
git-statusнапомнит вам напоминания типа «Ваша ветка опережает origin / master на 1 фиксацию». Вы' Вы также увидите это, когда вы проверите master.Если бы вы действительно хотели, вы могли бы написать ловушку после фиксации, которая просто уведомляет пользователя, как далеко они отошли от источника. Есть много способов подойти к этому, в зависимости от вашего рабочего процесса - возможно, просто продублируйте это сообщение о состоянии, возможно, найдите самую старую фиксацию в текущей ветке, которая не находится в источнике, чтобы вы могли сообщить им, сколько времени это было ... Обратите внимание, что включение хуков в репозиторий не является тривиальным: .git / hooks не отслеживается, поэтому вы должны создать символическую ссылку либо на каталог, либо на хуки внутри него в репо. Однако это можно автоматизировать с помощью сценария установки, так что это не так уж плохо!
Точно так же вы имеете дело с людьми, которые неделю работают в своей локальной рабочей копии svn без фиксации.
Это та же самая проблема.
Хотя есть технические решения, это действительно социальная проблема. Я бы начал с разговора с разработчиками и объяснил им, что они, по сути, работают изолированно от остальной части проекта. Эта изоляция представляет собой риск для проекта. Помните, что это, вероятно, не умышленное незнание. Они просто забывают, что фиксация больше не отправляется на центральный сервер svn.
Назначьте одного человека (руководителя проекта), отвечающего за получение информации от других разработчиков.