Comments 21
С нетерпением жду окончания
ЗЫ
«Это может спровоцировать неожиданное и часто необъяснимое чувство грусти среди программистов.» — убило :D
ЗЫ
«Это может спровоцировать неожиданное и часто необъяснимое чувство грусти среди программистов.» — убило :D
Мне нравится стиль изложения. Все доступно.
А меня убило «А Роза, господи прости, добавила МАНГО в ТОМ ЖЕ МЕСТЕ рецепта.» — как это знакомо!
Розовая консоль смотрится устрашающе.
А меня убило «А Роза, господи прости, добавила МАНГО в ТОМ ЖЕ МЕСТЕ рецепта.» — как это знакомо!
Розовая консоль смотрится устрашающе.
Оперативно О_о' Спасибо!
На этой консоли у Джоеля есть косяк:
консоль
После того как он сделал merge он не закомитился, а в логе у него уже есть changeset с мерджем
консольПосле того как он сделал merge он не закомитился, а в логе у него уже есть changeset с мерджем
Мммм…
В самой первой части «Переобучение для пользователей Subversion» было написано, что merge в hg работает как-то по другому и позволяет избегать «собраний у одного компьютера в попытке объединить несколько веток». Хотелось бы понять в чем заключается это отличие, потому как принципиальных различий между hg и svn не увидел (те же конфликты, та же схема их разрешения)…
В самой первой части «Переобучение для пользователей Subversion» было написано, что merge в hg работает как-то по другому и позволяет избегать «собраний у одного компьютера в попытке объединить несколько веток». Хотелось бы понять в чем заключается это отличие, потому как принципиальных различий между hg и svn не увидел (те же конфликты, та же схема их разрешения)…
В той же части написано, что одно из принципиальных отличий в том, как Subversion и Mercurial запоминают, что было изменено. Из-за того, что у Mercurial информации об изменениях больше, merge работает более надежно. Реже возникают конфликты, например.
Вот есть ответ на английском: stackoverflow.com/questions/43995/why-is-branching-and-merging-easier-in-mercurial-than-in-subversion
А подскажите, пожалуйста, какое решение возможно для такой ситуации:
Есть файл, который нельзя исключать из репозитария, но в строчке ХХ у одного разработчика должно стоять одно значение, а у другого — другое. Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя. Городить логику из if-else тоже не хочется.
Как быть?
Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
Есть файл, который нельзя исключать из репозитария, но в строчке ХХ у одного разработчика должно стоять одно значение, а у другого — другое. Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя. Городить логику из if-else тоже не хочется.
Как быть?
Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
> Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
Не-а.
> Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя.
По каким? :-)
Не-а.
> Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя.
По каким? :-)
Чтобы не выносить файл, имеющий отношение к проекту за каталог проекта?
Вообще задача, имхо, довольно частая: разработчиков много, настройки доступа к development серверам (логины/пароли) у каждого свои, но файл с дефолтными настройками должен быть в центральном репозитории (чтобы новый разработчик/пользователь мог его получить), а в рабочих копиях пользователя должны стоять его правки, не синхронизирующиеся с центральным сервером (но в случае hg/git поддерживающие историю правок и т. п. — в svn локальных коммитов нет, а значит выход только ignore) — как сделать чтобы файл клонировался с центрального репа, но потом изменения (модификации отдельных строк, добавления/удаление строк обрабатывается штатно) в локальном имели автоматический приоритет при пуллинге с центрального, но при пушинге на центральный приоритет имели центральные без постоянного ручного разрешения конфликтов. Реально малой кровью?
Вообще задача, имхо, довольно частая: разработчиков много, настройки доступа к development серверам (логины/пароли) у каждого свои, но файл с дефолтными настройками должен быть в центральном репозитории (чтобы новый разработчик/пользователь мог его получить), а в рабочих копиях пользователя должны стоять его правки, не синхронизирующиеся с центральным сервером (но в случае hg/git поддерживающие историю правок и т. п. — в svn локальных коммитов нет, а значит выход только ignore) — как сделать чтобы файл клонировался с центрального репа, но потом изменения (модификации отдельных строк, добавления/удаление строк обрабатывается штатно) в локальном имели автоматический приоритет при пуллинге с центрального, но при пушинге на центральный приоритет имели центральные без постоянного ручного разрешения конфликтов. Реально малой кровью?
Про svn:
Берём папку, кладём в неё конфиг и коммитим это дело.
В свойствах папки ставим файл в игнор (или *)
И это коммитим.
У разработчика:
В черепахе вешаем хук на чекаут, который будет подкладывать индивидуальный конфиг в папку для конфигов.
(или не делаем игнор, а в хуке меняем логин пароль к БД и т.п. в забраном из репозитория файле)
Берём папку, кладём в неё конфиг и коммитим это дело.
В свойствах папки ставим файл в игнор (или *)
И это коммитим.
У разработчика:
В черепахе вешаем хук на чекаут, который будет подкладывать индивидуальный конфиг в папку для конфигов.
(или не делаем игнор, а в хуке меняем логин пароль к БД и т.п. в забраном из репозитория файле)
В опрос не в том, зачем это нужно (прекрасно понимаю описанную вами ситуацию). вопрос в том, при каких условиях не применима схема с двумя файлами config.global + config.local, при которой второй записан в игнор и переопределяет отдельные параметры?
Сторонним приложением (фреймворк или, чаще, CMS) для которого ведётся разработка, например, модуля, такая логика «наследования» может быть не предусмотрена (или в ТЗ к разрабатываему явно указано, что все настройки должны храниться в config.ini). Обойти можно, выше вон хук советуют, но костыль же, не?
Да, тоже считаю костылём. Имхо, если возникает проблема с многими разработчиками, которые не могу договориться об одинаковых настройках своих окружений, то при таких масштабах можно и дописать вышестоящий фреймворк. Ну а остальным придётся костылять.
Имхо, различия конфига между проектом и его девелоперской копией (не говоря уже о продакшне) есть не костыль, а суровая реальность, и честный выход из положения — это в каком-нибудь bootstrap'е или прямо в конфиг-файле приложения подцеплять свой отдельный конфиг.
Ещё есть вариант, что для развертывания проекта на своей машине разраб должен запустить скрипт, который запишет нужный конфиг, тогда конфиги для всех разрабов можно и в версиях хранить. Этакая мини-интеграция. Её можно на хук повесить, чтобы проводилась при апдейте рабочей копии или при изменении определенных файлов.
Ещё есть вариант, что для развертывания проекта на своей машине разраб должен запустить скрипт, который запишет нужный конфиг, тогда конфиги для всех разрабов можно и в версиях хранить. Этакая мини-интеграция. Её можно на хук повесить, чтобы проводилась при апдейте рабочей копии или при изменении определенных файлов.
Я точно знаю, что для этих целей можно использовать mq, расширение, которое входит в базовую поставку. Но как точно — не подскажу.
А если у меня при конфликте в слиянии открывается вим. А в нем только 3 окна: исходная версия, моя версия и версия другого человека. Четвертого окна, для правки изменений нету. Как поступать в этом случае?
Как-то Джоэль обошел сторой сам процесс слияния в kdiff3, никак не могу понять, что там нажимать. Слишком много кнопок(
Sign up to leave a comment.
Hg Init: Часть 5. Процесс слияния