VLLV (03.07.2020 09:32, просмотров: 9371)-
- Ну если совсем никак...то сделать ручной мерж...не сливать через svn...а тупо winmerge к примеру - sav6622(03.07.2020 10:00)
- Как правило обычно давно разошедшуюся ветку влить в транк. Тогда
обычно коммиты из транка обычным образом подмерживаются в ветку (с
разрешением коллизий), потом делается "svn merge --reintegrate" для
мержа ветки в транк -- там мержится за один коммит содержащий дифф
между ветками. У тебя примерно похожая стратегия должна быть, надо
выбрать кто будет "транком" только. - fk0(03.07.2020 09:53)
- Только за поправки проголосовали, а тут такое издевательство над языком. - BlackMorda(03.07.2020 15:21)
- Чета тупиково. Чем больше смотрю на различия, тем больше понимаю,
что без интеллекта никуда. Лучше сразу присесть на день, чем слить
и разгребать два дня. - VLLV(03.07.2020 10:35)
- Инерция ума, думать что merge все сделает как-то автоматом. Merge
текстовый, семантику программы текстовое слияние не учитывает. Даже
если не было конфликтов, это не значит что программа заработает,
поэтому необходимо смотреть каждый diff. Использовал и посоветую
kdiff3. Выглядит не так хорошо, зато у kdiff3 весьма продвинутый
алгоритм нахождения изменений, так что половину работы он уже
делает. - RxTx(03.07.2020 14:48, ссылка)
- "Весьма продвинутый алгоритм" 3-way merge у всех подобных средств.
Более того, сам svn merge/diff так и работает. И лучше/проще это
поручить ему на уровне отдельных коммитов, чем мержить
рукамисторонней тулзой всё сразу и целиком. - fk0(03.07.2020 18:23, ссылка)- Нет, ты понял неправильно. Речь не про 3way merge. В сообщении есть
ссылка, посмотри там про kdiff3. RxTx(795 знак., 03.07.2020 20:14)
- Я видел kdiff3. Он ничем не лучше мержа в редакторе, после того как
svn оставил там свои комментарии насчёт конфликта. Просто нужно
научиться пользоваться. Более того, в сложных случаях в редакторе
ПРОЩЕ, в kdiff3 пестрит в глазах, всё красное, ничего не понять. И
да, meld таки более нагляден, чем kdiff3. Единственное преимущество
kdiff3 -- он умеет 3way merge без SVN/git, но на кой оно надо
непонятно, если svn/git тоже умеют. Ещё умеет сам решать конфликты,
но ну его нафиг fk0(43 знак., 03.07.2020 23:16)
- > Я видел *. Он ничем не лучше *. Просто нужно научиться пользоваться. RxTx(21 знак., 04.07.2020 00:06)
- Я видел kdiff3. Он ничем не лучше мержа в редакторе, после того как
svn оставил там свои комментарии насчёт конфликта. Просто нужно
научиться пользоваться. Более того, в сложных случаях в редакторе
ПРОЩЕ, в kdiff3 пестрит в глазах, всё красное, ничего не понять. И
да, meld таки более нагляден, чем kdiff3. Единственное преимущество
kdiff3 -- он умеет 3way merge без SVN/git, но на кой оно надо
непонятно, если svn/git тоже умеют. Ещё умеет сам решать конфликты,
но ну его нафиг fk0(43 знак., 03.07.2020 23:16)
- Как то не слабо получается "на уровне отдельных коммитов". К
примеру если их было 100 шт, в каждом по 10 файлов изменённых и
надо потратить к примеру 5 мин на каждый файл - то получим 5000 мин
работы что примерно 10,5 рабочих дней по 8 часов без перекуров. Тут
либо не доводить до такого расхождения, либо выбрать ветку где
меньше актуальных изменений (в крайних коммитах) и её применить к
другой. - Zoro(03.07.2020 19:04)
- Большая часть изменений, подразумевается, вливается таки
безконфликтно (в одной ветке меняли одно, в другой другое) и ты не
тратишь на них время. В случае 2-стороннего диффа у тебя все
изменения -- конфликт и ты должен думать головой. Что сильно
тяжелей. Наверное можно взять рекламируемый здесь kdiff3 и дать ему
три копии: общую базу, левый вариант и правый, тогда будет проще.
Meld тоже так умеет, вроде. Потом в случае единичных коммитов
бывает проще понять, что делается, fk0(66 знак., 03.07.2020 23:21)
- Вдохновился пощщупать какие-нибудь другие тулзы. По ссылке выше
крендели упоминали некий semanticmerge - RxTx(04.07.2020 01:02, ссылка)
- Серебряной пули -- нет. Профессионалы всё делают в обычном
редакторе. - fk0(04.07.2020 12:11)
- Неправда. Профессионал подбирает инструмент под свою задачу. Стремясь оптимизировать затраты. Но если так звезды сложились и делать нечего, может воспользоваться и примитивными инструментами. (Таково мое личное мнение без претензий на объективную истину). Вместе с тем, верно то что не надо искать совершенства до бесконечности. Сложные инструменты создают свои проблемы, потому стремиться надо к KISS. - RxTx(04.07.2020 12:24)
- Серебряной пули -- нет. Профессионалы всё делают в обычном
редакторе. - fk0(04.07.2020 12:11)
- В действительности, все зависит от задач. Я сейчас давно уже не
пользуюсь kdiff'ом тупо потому что мне лень его прописать в
настройки tortoise. :) Пользуюсь первым что под руку попало -
WinMerge, мне сравнить пару-тройку файлов хватает. Прописывается
она автоматом. Еще сравниваю им директории. А вот тогда, в
2012..2015 передо мной (и также парнями из команды) вставали очень
суровые задачи. Перепробовал всё что можно, множество мержилок.
BeyondCompare точно, Araxis Merge RxTx(783 знак., 04.07.2020 00:55, ссылка)
- Вот поэтому по коммитам работать может быть и проще. Потому, что
однозначно понятно чей коммит (не)взять и можно при мерже выбрать
стратегию разрешения конфликта и тот же git/svn сработает
автоматически по большей части. - fk0(04.07.2020 12:16)
- Угу - RxTx(04.07.2020 12:21)
- А да, удалять тоже приходится. И потом еще и возникает проблема твоей инкрементальной работы. Что постепенно наделал ты, что было старое, что приехало из нового проекта. Нельзя смержить всё сразу тупо потому что ты должен компилять проект и проверять его. (это я постепенно вспоминаю че было, этот адок) - RxTx(04.07.2020 01:06)
- Вот поэтому по коммитам работать может быть и проще. Потому, что
однозначно понятно чей коммит (не)взять и можно при мерже выбрать
стратегию разрешения конфликта и тот же git/svn сработает
автоматически по большей части. - fk0(04.07.2020 12:16)
- Вдохновился пощщупать какие-нибудь другие тулзы. По ссылке выше
крендели упоминали некий semanticmerge - RxTx(04.07.2020 01:02, ссылка)
- Работать покоммитно крайне странное предложение fk0. Крупные
проекты мержить можно неделю-две, ничего не поделаешь. - RxTx(03.07.2020 19:48)
- Ну почему странно? - покоммитный мерж (блюстителям русского языка -
"пошаговое слияние") нормально работает в автоматическом режиме в
svn, это естественно проще. - VLLV(03.07.2020 23:33)
- Когда фрагменты маленькие, инкрементальные, то всегда все проще.
Просто не зная объемов я судил по тому что было у меня. У нас на
годовом проекте было несколько тысяч коммитов (так припоминаю
цифери в версиях 2700...3900 точно). А смержить пару таких веток
(например, впилить всю годовую разработку из advanced
spinoff-проекта в базовую линейку) сажали одного человека. Это не
Embedded, другое. - RxTx(04.07.2020 00:31)
- Ну, у меня не смертельно, до полусотни в ветке. Расхождение
обведено красным, 2.5 года назад. Заказчик иногда просто бесит. VLLV(1 знак., 04.07.2020 01:47, картинка)
- Тогда, значит, справитесь. Ну, пожелаю удачи! - RxTx(04.07.2020 12:14)
- Ну, у меня не смертельно, до полусотни в ветке. Расхождение
обведено красным, 2.5 года назад. Заказчик иногда просто бесит. VLLV(1 знак., 04.07.2020 01:47, картинка)
- Когда фрагменты маленькие, инкрементальные, то всегда все проще.
Просто не зная объемов я судил по тому что было у меня. У нас на
годовом проекте было несколько тысяч коммитов (так припоминаю
цифери в версиях 2700...3900 точно). А смержить пару таких веток
(например, впилить всю годовую разработку из advanced
spinoff-проекта в базовую линейку) сажали одного человека. Это не
Embedded, другое. - RxTx(04.07.2020 00:31)
- Ну почему странно? - покоммитный мерж (блюстителям русского языка -
"пошаговое слияние") нормально работает в автоматическом режиме в
svn, это естественно проще. - VLLV(03.07.2020 23:33)
- Большая часть изменений, подразумевается, вливается таки
безконфликтно (в одной ветке меняли одно, в другой другое) и ты не
тратишь на них время. В случае 2-стороннего диффа у тебя все
изменения -- конфликт и ты должен думать головой. Что сильно
тяжелей. Наверное можно взять рекламируемый здесь kdiff3 и дать ему
три копии: общую базу, левый вариант и правый, тогда будет проще.
Meld тоже так умеет, вроде. Потом в случае единичных коммитов
бывает проще понять, что делается, fk0(66 знак., 03.07.2020 23:21)
- Нет, ты понял неправильно. Речь не про 3way merge. В сообщении есть
ссылка, посмотри там про kdiff3. RxTx(795 знак., 03.07.2020 20:14)
- "Весьма продвинутый алгоритм" 3-way merge у всех подобных средств.
Более того, сам svn merge/diff так и работает. И лучше/проще это
поручить ему на уровне отдельных коммитов, чем мержить
- Проще втаскивать по одному коммиту и решать конфликты, чем полностью ручной мерж. Хотя иногда может быть и ручной мерж проще -- зависит от ситуации. Волшебной программы, чтоб сама всё сделала -- нет. Иначе бы и код за тебя давно уже программы писали. Диффы лучше смотрятся в meld или (g)vim (vimdiff). Лучше в meld. Для Vim есть полезный плагин -- DirDiff. - fk0(03.07.2020 10:38)
- Инерция ума, думать что merge все сделает как-то автоматом. Merge
текстовый, семантику программы текстовое слияние не учитывает. Даже
если не было конфликтов, это не значит что программа заработает,
поэтому необходимо смотреть каждый diff. Использовал и посоветую
kdiff3. Выглядит не так хорошо, зато у kdiff3 весьма продвинутый
алгоритм нахождения изменений, так что половину работы он уже
делает. - RxTx(03.07.2020 14:48, ссылка)
- визуальный свн? - SciFi(03.07.2020 09:40, ссылка)
- Спасибо - VLLV(03.07.2020 10:35)
