Разрешение конфликтов Subclipse
Мы все еще используем его в большой степени в нашем коде для поиска тысяч ACLS много тысяч времен секунда. Это полезно, потому что ACLs статичны, после того как они входят из файла, и мы можем перенести расход роста массива, как мы добавляем к нему при начальной загрузке. Ослепительно быстро однажды его выполнение также.
, Когда можно искать 255 массивов элемента в самое большее 7, сравнивают/переходят (511 в 8, 1023 в 9, и т.д.), Вы видите, что двоичный поиск о том, с такой скоростью, как можно добраться.
1 ответ
Да, вы правы. Для этого нет кнопки. в режиме просмотра различий (вид бок о бок) элементы красного цвета конфликтуют. Их нельзя объединить автоматически. Вы должны просмотреть конфликтующий элемент и вручную разрешить его, скопировав / отредактировав блок кода, который находится в конфликте.
После фиксации или обновления из репозитория (Синхронизация с репозиторием) вы увидите в представлении консоли, что некоторые элементы находятся в конфликте. Когда вы посмотрите на этот файл в Package, вы увидите 3 файла рядом с исходным файлом:
myfile.txt (original file)
myfile.txt.mine
myfile.txt.r3293
myfile.txt.r3501
Щелкните правой кнопкой мыши исходный файл и выберите Team -> Edit Conflict. В предоставленном Diff View отредактируйте файл слева, чтобы он соответствовал желаемому окончательному результату. (т.е. вы можете сохранить некоторые изменения и скопировать новое обновление из ревизии в SVN, отмените все изменения и сохраните только ваши изменения и т. д.) После того, как вы закончите, сохраните файл. Снова щелкните правой кнопкой мыши исходный файл, затем выберите «Команда» -> «Отметить восстановленный».
Вы увидите, что добавленные 3 файла исчезнут. Теперь вы можете «безопасно» зафиксировать свою работу.
Нет простого способа сделать это, поскольку SVN не может решить, какой вариант лучше всего, когда возникает такой конфликт.