OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Воскресенье, 08 Декабрь, 2019 14:07

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 63 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
СообщениеДобавлено: Пятница, 16 Август, 2013 20:07 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
И слияние и уведомление о коллизиях замечательно работают в гите уже сейчас. Даже с документами ББ. Проблема не в том, что это не делается. Проблема в том, что в случае коллизии система контроля версий только и сможет сказать "у вас коллизия". И чтобы с ней разобраться, придётся вручную сравнивать два документа.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 21:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9162
Откуда: Россия, Орёл
Так, теперь выяснилось, что под автослиянием коллеги понимают слияние веток (наборов файлов). А не слияние конфликтующих изменений одного файла.
Автослияние веток прекрасно работает и с бинарниками, в чём проблема-то...


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 21:21 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2933
Откуда: г. Ярославль
Valery Solovey писал(а):
И слияние и уведомление о коллизиях замечательно работают в гите уже сейчас. Даже с документами ББ. Проблема не в том, что это не делается. Проблема в том, что в случае коллизии система контроля версий только и сможет сказать "у вас коллизия". И чтобы с ней разобраться, придётся вручную сравнивать два документа.
Проблема в том, что никакая система контроля версиий не способна различить коллизии на уровне алгоритма, а срабатывает только на уровне строк, насколько я знаю.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 21:26 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Илья Ермаков писал(а):
слияние конфликтующих изменений
Почему конфликтующих? Просто изменений.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 21:29 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1162
Откуда: Tel-Aviv
Илья Ермаков писал(а):
Так, теперь выяснилось, что под автослиянием коллеги понимают слияние веток (наборов файлов). А не слияние конфликтующих изменений одного файла.
Именно так. Собственно, одна из проблем при работе с контролем версий - это когда VCS автоматически пытается слить два файла в один, порождая конфликт. Благо, конфликты сам он не решает, а оставляет разработчику.
На работе использую git, редко - Subversion.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 21:32 
Аватара пользователя

Зарегистрирован: Пятница, 25 Сентябрь, 2009 13:10
Сообщения: 1162
Откуда: Tel-Aviv
Иван Кузьмицкий писал(а):
Проблема в том, что никакая система контроля версиий не способна различить коллизии на уровне алгоритма, а срабатывает только на уровне строк, насколько я знаю.
Если можно, лучше привести пример, при котором при слиянии веток произойдёт конфликт на уровне программы, при участии VCS в авто-слиянии.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 21:43 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Иван Кузьмицкий писал(а):
Проблема в том, что никакая система контроля версиий не способна различить коллизии на уровне алгоритма, а срабатывает только на уровне строк, насколько я знаю.
Алгоритмы в Обероне останутся алгоритмами и после переписывания на других языках. Так что с одной стороны - да, если могут существовать коллизии на уровне алгоритма, то эти инструменты их не обработают правильно (как и ещё многое другое), но с другой стороны, в обычных текстовых файлах других языков программирования они тоже не могут быть обработаны. А самое приятное, что это и не надо. Поэтому-то инструменты контроля версий и могут существовать.

Иван Кузьмицкий писал(а):
срабатывает только на уровне строк, насколько я знаю.
Задача обнаружения конфликта - это задача на пересечение множеств. Есть один дифф с группой изменений. Каждое изменение представлено диапазоном. Диапазоном байт в простейшем случае. Появляется ещё один дифф. Если какой-то из диапазонов нового диффа пересекается с диапазоном первого, то имеем конфликт.

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


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 22:23 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Роман М. писал(а):
Если можно, лучше привести пример, при котором при слиянии веток произойдёт конфликт на уровне программы, при участии VCS в авто-слиянии.

Все просто. Если система автослияния ничего не знает о структуре содержимого текстовика, то конфликт это файл который правился в обеих ветках. Если система умеет распарсить текст до процедур, то конфликт это процедура, которая правилась в обеих ветках. И так далее...

Т.е. все зависит от того, на сколько глубоко ситема может проанализировать исходник и построить по нему структурное дерево. В 1С мердж работает на уровне процедур, например.


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Пятница, 16 Август, 2013 22:36 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Вот еще информация в тему:
Цитата:
Ну вот допустим есть некий модуль версии 1.0. В модуле две процедуры А() и В()
Два человека независимо друг от друга вносят изменения в свои копии этого модуля, т.е. появляются два потомка.

Сравнивая три файла (исходный и два потомка) мы обнаружим что каждая процедура:
1) Не изменялась ни у первого, ни у второго потомка
2) Изменялась только у первого
3) Изменялась только у второго
4) Изменялась у обоих

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

Ну вот как то так. :)

http://oberspace.dyndns.org/index.php/t ... ml#msg4269


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Август, 2013 18:20 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9162
Откуда: Россия, Орёл
Valery Solovey писал(а):
Илья Ермаков писал(а):
слияние конфликтующих изменений
Почему конфликтующих? Просто изменений.


Ну, в том же Mercurial любые изменения, параллельно сделанные, даже если они относятся к разным файлам, всё равно нуждаются в pull - merge - commit для их слияния. Меня это сначало дико удивило после SVN :)


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Суббота, 17 Август, 2013 18:47 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 2472
Все что нужно, на мой взгляд, чтобы F9 не пропускал отображения и различия в форматировании при анализе документов! Тогда все будет зашибись. Ведь не только код приходится сравнивать, а еще и документацию бывает.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Воскресенье, 18 Август, 2013 15:15 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Илья Ермаков писал(а):
Если хотите мое мнение глобальное, перспективное - то я за семантическое представление исходников

А у нас тут однако мысли сходятся. :)
От txt в исходниках нужно уходить. Странный это процесс... хранить в txt и каждый раз парсить для синтаксического контроля, подсветки и прочего... Да и редактировать по сути дерево как текст тоже странно. Но я об этом не заикаюсь, т.к. не представляю как это реализовать. И уж на это точно никто не пойдет в ББ :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 15:30 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Илья Ермаков писал(а):
А всё, в конечном счёте, из-за не столь нужной фичи автослияния ))


Вот прям сейчас подвернулся жизненный пример. :D
Пилю значит одну разработку. Клиент делает перепостановку задачи в начале месяца и просит внести изменения до конца месяца. На данный момент я эти изменения закодил, но не тестировал, т.е. отдать в продакшен не могу. Сегодня звонит клиент и говорит что нужно кровь из носа запилить дополнительную фичу до конца месяца. Ресурсов у меня не хватит на то и другое. Договариваюсь, что предыдущую задачу откладываем на след. месяц.
Обе задачи вносят изменения в логику одного и того же алгоритма, который, естественно, заключен в одном модуле. Сейчас я нахожусь на ревизии 469. Мне нужно вернуться к ревизии 450, выделить ветку и закодить вторую задачу. А в след. месяце нужно будет допилить задачу в первой ветке, и выполнить слияние.

Вот такой простой жизненный пример.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 16:11 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2933
Откуда: г. Ярославль
ilovb писал(а):
...Клиент делает перепостановку задачи в начале месяца и просит внести изменения до конца месяца. На данный момент я эти изменения закодил, но не тестировал, т.е. отдать в продакшен не могу. Сегодня звонит клиент и говорит что нужно кровь из носа запилить дополнительную фичу до конца месяца. Ресурсов у меня не хватит на то и другое. Договариваюсь, что предыдущую задачу откладываем на след. месяц.
Обе задачи вносят изменения в логику одного и того же алгоритма, который, естественно, заключен в одном модуле. Сейчас я нахожусь на ревизии 469. Мне нужно вернуться к ревизии 450, выделить ветку и закодить вторую задачу. А в след. месяце нужно будет допилить задачу в первой ветке, и выполнить слияние.

Вот такой простой жизненный пример.


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

Если же автослияние не сломает ничего, то изменения вносятся, по сути, в разные алгоритмы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 17:02 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Да нет, все норм.

Процедура Алгоритм()
...
Подалгоритм1() // тут изменения по первой задаче
...
Подалгоритм2() // тут изменения по второй задаче
... // несколько правок в основной процедуре по первой задаче
КонецПроцедуры

Никакого фарша.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 18:01 

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2933
Откуда: г. Ярославль
Совершенно случайно так получилось, что вносимые изменения не пересекаются, не ломают логику процедуры и не портят контракт.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 18:06 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4354
Откуда: Россия, Орёл
ilovb писал(а):
Вот такой простой жизненный пример.

В общем-то, потому что везде такая хреновая организация производства и возникают такие инструменты как merge в хранилищах.

P.S. На всякий случай уточняю: хранилища с версиями нужны сами по себе.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 18:59 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Иван Кузьмицкий писал(а):
Совершенно случайно так получилось, что вносимые изменения не пересекаются, не ломают логику процедуры и не портят контракт.

Может быть. А может быть и наоборот. Не помню случаев когда при слиянии изменения пересекались. Возможно я очень везучий. Но мне кажется, что как раз пересечения маловероятны.
В любом случае слияние конфликта делает человек...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 19:02 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4354
Откуда: Россия, Орёл
Только человек не всегда сможет учесть побочные неочевидные эффекты...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: BlackBox Merge tool
СообщениеДобавлено: Среда, 21 Август, 2013 19:11 

Зарегистрирован: Вторник, 30 Июнь, 2009 14:58
Сообщения: 1549
Борис Рюмшин писал(а):
В общем-то, потому что везде такая хреновая организация производства и возникают такие инструменты как merge в хранилищах.

Не очень понимаю о какой организации вы говорите.
Про то, как клиент ставит задачи?
У нас так всегда. Это нормальный рабочий момент.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 63 ]  На страницу Пред.  1, 2, 3, 4  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2019, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB