Мой первый ответ, когда я прочитал ваш вопрос: «Конечно, технически возможно, но действительно очень плохая идея».
Я немного вернусь после просмотра других комментариев. Хорошо, у каждого пользователя может быть локальный репозиторий, отдельный от центрального репозитория, и использовать его для сохранения контрольных точек во время работы. В этом случае они могут быть полностью отдельными VCS, и это не будет иметь значения.
Но если вы думаете о двух разных VCS, одновременно содержащих ваш центральный репозиторий, это технически возможно, но действительно очень плохая идея. Весь смысл VCS состоит в том, что вы ведете историю всех изменений, внесенных в файлы, что вы можете видеть, какие изменения были внесены, когда и - если пользователи включают в себя наполовину достойные комментарии к коммитам - почему. Если у клиента, имеющего версию от 19 июня 2007 года, возникла проблема, вы можете получить код в точности так, как он существовал 19 июня 2007 года, поэтому вы отлаживаете код, который фактически выполняет пользователь. Если вы обнаружите, что последнее изменение было большой ошибкой, вы можете откатиться назад. И т. Д.
Но если у вас есть два репозитория ... Собираетесь ли вы делать каждый коммит одинаково для обоих репозиториев? По крайней мере, это куча дополнительной работы. В худшем случае, рано или поздно кто-то совершит ошибку, забудет совершить одно или не совершить до следующего дня после того, как кто-то другой сделал промежуточный коммит, и репозитории на самом деле не будут идентичны. Или вы собираетесь чередовать, иногда выходя из A, а иногда из B? Но тогда никто никогда не узнает, что в них есть.
Я мог видеть использование двух разных VCS в течение нескольких дней или нескольких недель, просто чтобы опробовать их и посмотреть, как они работают, почувствовать, что вам больше нравится. Но даже при этом я бы не стал делать это как свою производственную систему. У меня был бы настоящий серийный VCS, а затем еще один на той стороне, с которой мы играем, но никто не считает это авторитетным.