Pull to refresh

Comments 21

С нетерпением жду окончания

ЗЫ

«Это может спровоцировать неожиданное и часто необъяснимое чувство грусти среди программистов.» — убило :D
Мне нравится стиль изложения. Все доступно.
А меня убило «А Роза, господи прости, добавила МАНГО в ТОМ ЖЕ МЕСТЕ рецепта.» — как это знакомо!
Розовая консоль смотрится устрашающе.
На этой консоли у Джоеля есть косяк:
консоль
После того как он сделал merge он не закомитился, а в логе у него уже есть changeset с мерджем
Мммм…

В самой первой части «Переобучение для пользователей Subversion» было написано, что merge в hg работает как-то по другому и позволяет избегать «собраний у одного компьютера в попытке объединить несколько веток». Хотелось бы понять в чем заключается это отличие, потому как принципиальных различий между hg и svn не увидел (те же конфликты, та же схема их разрешения)…
В той же части написано, что одно из принципиальных отличий в том, как Subversion и Mercurial запоминают, что было изменено. Из-за того, что у Mercurial информации об изменениях больше, merge работает более надежно. Реже возникают конфликты, например.
Это я читал, но из этой статьи я сделал вывод, что конфликт возникает в том случае, когда редактировалась одна и та же строка файла одновременно. В svn точно так же.

Другими словами, хотелось бы увидеть пример, где работа merge действительно отличается.
Поддерживаю! Очень хочется увидеть реальный пример, где Subversion выдаст конфликт а Mercurial все объединит.
А подскажите, пожалуйста, какое решение возможно для такой ситуации:
Есть файл, который нельзя исключать из репозитария, но в строчке ХХ у одного разработчика должно стоять одно значение, а у другого — другое. Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя. Городить логику из if-else тоже не хочется.
Как быть?
Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
> Может, можно сделать игнор не всего файла, а какой-то строки или нескольких строк?
Не-а.

> Допустим, вынести эту настройку во внешний файл, который не участвует в репозитарии, по каким-то причинам нельзя.
По каким? :-)
Чтобы не выносить файл, имеющий отношение к проекту за каталог проекта?

Вообще задача, имхо, довольно частая: разработчиков много, настройки доступа к development серверам (логины/пароли) у каждого свои, но файл с дефолтными настройками должен быть в центральном репозитории (чтобы новый разработчик/пользователь мог его получить), а в рабочих копиях пользователя должны стоять его правки, не синхронизирующиеся с центральным сервером (но в случае hg/git поддерживающие историю правок и т. п. — в svn локальных коммитов нет, а значит выход только ignore) — как сделать чтобы файл клонировался с центрального репа, но потом изменения (модификации отдельных строк, добавления/удаление строк обрабатывается штатно) в локальном имели автоматический приоритет при пуллинге с центрального, но при пушинге на центральный приоритет имели центральные без постоянного ручного разрешения конфликтов. Реально малой кровью?
Про svn:
Берём папку, кладём в неё конфиг и коммитим это дело.
В свойствах папки ставим файл в игнор (или *)
И это коммитим.

У разработчика:
В черепахе вешаем хук на чекаут, который будет подкладывать индивидуальный конфиг в папку для конфигов.

(или не делаем игнор, а в хуке меняем логин пароль к БД и т.п. в забраном из репозитория файле)
В опрос не в том, зачем это нужно (прекрасно понимаю описанную вами ситуацию). вопрос в том, при каких условиях не применима схема с двумя файлами config.global + config.local, при которой второй записан в игнор и переопределяет отдельные параметры?
Сторонним приложением (фреймворк или, чаще, CMS) для которого ведётся разработка, например, модуля, такая логика «наследования» может быть не предусмотрена (или в ТЗ к разрабатываему явно указано, что все настройки должны храниться в config.ini). Обойти можно, выше вон хук советуют, но костыль же, не?
Да, тоже считаю костылём. Имхо, если возникает проблема с многими разработчиками, которые не могу договориться об одинаковых настройках своих окружений, то при таких масштабах можно и дописать вышестоящий фреймворк. Ну а остальным придётся костылять.
Имхо, различия конфига между проектом и его девелоперской копией (не говоря уже о продакшне) есть не костыль, а суровая реальность, и честный выход из положения — это в каком-нибудь bootstrap'е или прямо в конфиг-файле приложения подцеплять свой отдельный конфиг.

Ещё есть вариант, что для развертывания проекта на своей машине разраб должен запустить скрипт, который запишет нужный конфиг, тогда конфиги для всех разрабов можно и в версиях хранить. Этакая мини-интеграция. Её можно на хук повесить, чтобы проводилась при апдейте рабочей копии или при изменении определенных файлов.
Я точно знаю, что для этих целей можно использовать mq, расширение, которое входит в базовую поставку. Но как точно — не подскажу.
А если у меня при конфликте в слиянии открывается вим. А в нем только 3 окна: исходная версия, моя версия и версия другого человека. Четвертого окна, для правки изменений нету. Как поступать в этом случае?
Редактировать прям в первом окне, это то которое результат.
1 — результат, 2 — ваша локальная версия, 3 — пришло с репо.
Как-то Джоэль обошел сторой сам процесс слияния в kdiff3, никак не могу понять, что там нажимать. Слишком много кнопок(
Sign up to leave a comment.

Articles