Mercurial: библиотека классов, которая будет существовать как для .NET 3.5, так и для 4.0?

Question

У меня довольно большая библиотека классов, написанная на .NET 3.5, которую я хотел бы обновить, чтобы сделать доступной и для .NET 4.0.

В этом процессе я вычеркну много старого мусора и перепишу некоторый код, чтобы лучше использовать новые классы и поддержку в .NET 4.0 (например, TPL.). Таким образом, библиотеки классов будут расходиться, но все же будут достаточно похоже, что некоторые исправления ошибок могут быть сделаны для обоих одинаковым образом.

Как мне лучше организовать эту библиотеку классов в Mercurial? Я использую Kiln (fogbugz), если это имеет значение.

Я думаю:

1. Именованные ветки в одном хранилище, затем могут пересаживать любые исправления от одного к другому
2. Безымянные ветки в одном репозитории, также можно пересадить, но я думаю, это будет выглядеть грязно
3. Отдельные репозитории, придется переопределять исправления ошибок (или использовать некоммерчески интегрированный инструмент сравнения, чтобы помочь мне)

Что бы вы сделали? (Любые другие альтернативы, которых у меня нет, также приветствуются.)

Обратите внимание, что библиотеки классов довольно сильно расходятся по областям, у меня есть некоторые остатки старого кода коллекционного типа, который делает что-то похожее на Linq, который я удалю, и некоторый код, использующий его, который я перепишу для использования Linq Методы вместо. Таким образом, простое копирование файлов проекта и использование разделов #if NET40..#endif не сработает. Кроме того, в версии 3.5 библиотеки классов не будет много новых функций, в основном просто критических исправлений ошибок, поэтому поддерживать обе версии одинаково «живыми» на самом деле не нужно. Таким образом, отдельные копии всех файлов достаточно хороши.

---

Редактировать От @ Руди ответ здесь , я думаю, что он говорит это:

1. Создайте две ветви (или оставьте одну «по умолчанию» и создайте другую ветку для другого пути, которая будет «default» = .NET 4.0 и «net35» = .NET 3.5 в моем случае)
2. Развивайте их по разным путям
3. Когда обнаружено критическое исправление, которое существует в обеих версиях (т. Е. В 3.5 и 4.0) и может быть исправлено в общем коде, поскольку версия 3.5 не будет накапливать много новых функций, это означает, что ошибка, скорее всего, присутствовала в оригинальной версии (до того, как я разветвился)
4. Таким образом, я создаю другую ветку, вне исходной версии (или очень близкую к ней), внедряю свое исправление, а затем объединяю этот совет с ветками 3.5 и 4.0, чтобы обновить их обе.

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

Answer 1

Я бы использовал два клона для разных сред (= в основном две анонимные ветви), возможно, также с разными именами ветвей в каждом клоне. Также я бы использовал новую ветвь для каждого исправления ошибки или взаимозаменяемой функции, начиная с максимально возможной точки ветвления, чтобы упростить слияние между основными ветвями. Я попытался бы разработать исправления ошибок в ветке 3.5, так как более вероятно, что исправления ошибок в дереве 4.0 вызовут проблемы слияния из-за других изменений там (я не говорю, что этот подход не вызывает никаких проблем).