Исходный сервер управления или клиент, который поддерживает полностью ручное обновление или слияние - PullRequest
0 голосов
/ 11 ноября 2019

Мы работаем над большим проектом на c #, который изначально находился под управлением исходного кода tfs, позже был перемещен в git и даже по разным причинам завершен в управлении исходным кодом svn.

Обновления этого приложения часто требуют измененийв нескольких сложных файлах c #, js и cshtml, поэтому регулярно происходит, что разные задачи заканчиваются изменением одних и тех же страниц и разделов кода, но для совершенно разных проблем, поэтому мы часто встречаемся с множеством одновременных, неконфликтных, изменений условий идругие разделы потока кода с теми же функциями.

Наша проблема в том, что система управления исходным кодом -every-, которую мы использовали, заканчивает работу с нашими файлами после обновления, поэтому мы хотели бы найти один источник контролясистема или один клиент, который позволяет ФАКТИЧЕСКОЕ ОБНОВЛЕНИЕ всех файлов. Мы тратим слишком много времени, чтобы убедиться в правильности обновлений, поэтому мы бы предпочли обновить вручную, чтобы убедиться, что все в порядке. Под этим мы подразумеваем, что из-за характера изменений, просто чтобы назвать две простейшие проблемы, с которыми мы столкнулись, некоторым выпадающим спискам присваивается значение, которое перезаписывается другим обновлением из другого кодера, позже иличто есть несколько назначений для того же скрытого поля ввода. Очевидно, что это не ошибка инструментов обновления, но это именно то, что происходит из-за характера нашей работы.

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

Что касается реальных конфликтов, мы 'Мы использовали способность tortoisesvn автоматически аннулировать весь файл, поэтому для этих файлов сравнение и разрешение конфликтов сделано намеренно вручную и позволяет нам сортировать проблемы по своему усмотрению.

Поэтому мы любезно спрашиваем: кто-нибудь знает об источнике контроляклиент или сервер, который позволяет вручную обновлять все файлы во время обновления / извлечения / извлечения?

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

Спасибо

Ответы [ 2 ]

0 голосов
/ 12 ноября 2019

Вы можете использовать git merge --no-commit для объединения другой ветви без ее фиксации, чтобы вы могли проверить изменения и затем зафиксировать те, которые вы хотите. Я не верю, что есть какие-либо инструменты хостинга Git, которые позволяют это, поэтому вам нужно выполнять каждое слияние вручную в командной строке.

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

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

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

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

0 голосов
/ 12 ноября 2019

internal:forcedump mergetool в Mercurial выполнит запрошенный трюк, но в любом случае это неверный путь и путь в никуда.

...