Существуют ли какие-либо инструменты слияния для контроля источника, которые понимают код?
Недавно я работал с большой базой кода, рефакторингом и, как правило, улучшал дизайн, чтобы увеличить охват. Кроме того, в целом ряде файлов я удалял избыток с помощью операторов, перемещал методы, чтобы аналогичные функции были близки друг к другу, добавляли регионы и т.д., Но фактически не изменяли функциональность кода в файле.
Между тем, в других местах команды другие разработчики исправляют ошибки и меняют строки кода здесь и там. Очевидно, что когда дело доходит до слияния, это может быть проблемой, поскольку номера строк больше не совпадают, и методы могут перемещаться.
Теперь я понимаю общее правило, что в среде с контролируемым источником может быть опасно перемещать методы, и мы решили, что это преимущество перевешивает стоимость. Однако я не понимаю, почему так должно быть.
Скажем, что мой начальный файл был простым калькулятором:
public class Calculator
{
public int Subtract(int a, int b)
{
return a + b;
}
public int Add(int a, int b)
{
return a + b;
}
}
И я решил, что хочу, чтобы методы были в алфавитном порядке:
public class Calculator
{
public int Add(int a, int b)
{
return a + b;
}
public int Subtract(int a, int b)
{
return a + b;
}
}
В то время как другой разработчик исправил ошибку в методе вычитания
public class Calculator
{
public int Subtract(int a, int b)
{
return a - b;
}
public int Add(int a, int b)
{
return a + b;
}
}
Стандартный инструмент слияния, вероятно, потребует, чтобы вы вручную объединили эти два файла, но тот, который понимал функциональность кода, мог бы легко согласовать эти два изменения. То же самое относится к удалению или добавлению других методов, комментариев, регионов или использованию операторов.
Итак, чтобы (наконец!) дошли до вопроса: есть ли какие-либо инструменты для слияния, которые имеют разумное понимание функциональности кода и могут объединить эти два файла выше, без какого-либо вмешательства человека? Если нет, почему бы и нет? Существуют ли какие-либо осложнения, которые делают эту проблему неразрешимой (конечно, понять, что это не так просто, как я подразумеваю), но почему-то невозможно понять, что я не вижу?)
Я использую С# в своем исходном коде и буду любить что-то, что сработало с этим, но меня интересует, существует ли это где-нибудь в мире программирования...
Я уже очень беспокоюсь о длине этого вопроса, но отредактировал, чтобы добавить, как я ожидаю, что интеллектуальная исходная система будет работать:
Когда исходный файл калькулятора был проверен в системе, он будет разбирать файл и создавать иерархию класса:
File: Calculator.cs
|
|--Class[0]: Calculator
|
|--Method[0]: Subtract
|
|--Line[0]: return a + b;
|
|--Method[1]: Add
|
|--Line[0]: return a +b;
(С дополнительными строками там для фигурных скобок и т.д.)
Когда я проверяю свой код (делая методы в алфавитном порядке), он обновляет иерархию выше, так что Subtract становится Method [1], а Add становится Method [0].
Второй разработчик проверяет свой код (который, очевидно, знает система управления версиями, основывается на оригинале) и замечает изменение в первую строку в вычитании. Теперь, вместо того, чтобы найти этот номер строки по номеру в общем файле, он знает, что он может найти его Calculator.cs/Calculator/Subtract/0, а тот факт, что метод изменил местоположение, не имеет значения, он все равно может сделать слияние.
Ответы
Ответ 1
Я думаю, что Исходный код в базе данных является одним из потенциальных ответов на ваш вопрос. Общая идея заключается в том, что у вас нет файлов версий, блоков версии кода. Система управления версиями знает о коде DOM и позволяет вам запрашивать код DOM для проверки функций, классов, "что-вы", для редактирования, компиляции и т.д.
Поскольку порядок методов не обязательно имеет значение, они не хранятся в базе данных с учетом любого порядка. Когда вы проверяете класс, вы можете указать порядок, который вам больше нравится (в алфавитном, общедоступном/защищенном/приватном и т.д.). Единственные изменения, которые имеют значение, такие, как, например, при переключении +
на -
. У вас не будет конфликта из-за переупорядочения методов.
К сожалению, SCID все еще очень молод, и для него не так много инструментов. Тем не менее, это довольно интересная эволюция в способе просмотра и редактирования кода.
Изменить: Здесь другая ссылка для SCID
Ответ 2
Наш подход с Plastic SCM еще далек от того, чтобы быть "полным", но он уже выпущен и может помочь в таких ситуациях. Взгляните на Xmerge. Конечно, обратная связь будет более чем приветствуемой и предоставит некоторые бесплатные лицензии; -)