Глюки в p4 не то чтобы смертельны, по крайней мере, данные он не теряет. В нашем случае он (точнее его прокси) ложился по SEGV при выкачке больших объемов данных. Я бы больше волновался за то, что пользователи вас проклянут: клиентский интерфейс там ОЧЕНЬ своеобразный (хотя есть и хорошие вещи, вроде time-lapse view).
Про clearcase -- ну, возможно, у них была та самая dev team про которую пишут выше.
Кстати, а что вы такого кладете в svn на несколько сотен гиг? У нас есть один такой репозиторий, но он ровно один и даже до одной сотни по-моему еще не дотянул, хотя в него лет десять валят всякое говно. Собственно, я к чему: даже если git не держит репы на полтерабайта, необходимость эти полтерабайта держать именно под одной историей version control'а как правило -- антипаттерн (наш случай не исключение). В гите можно же в принципе креативно порезать это все с помощью submodules/subtree на более мелкие части.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2013-10-18 06:53 pm (UTC)Глюки в p4 не то чтобы смертельны, по крайней мере, данные он не теряет. В нашем случае он (точнее его прокси) ложился по SEGV при выкачке больших объемов данных. Я бы больше волновался за то, что пользователи вас проклянут: клиентский интерфейс там ОЧЕНЬ своеобразный (хотя есть и хорошие вещи, вроде time-lapse view).
Про clearcase -- ну, возможно, у них была та самая dev team про которую пишут выше.
Кстати, а что вы такого кладете в svn на несколько сотен гиг? У нас есть один такой репозиторий, но он ровно один и даже до одной сотни по-моему еще не дотянул, хотя в него лет десять валят всякое говно. Собственно, я к чему: даже если git не держит репы на полтерабайта, необходимость эти полтерабайта держать именно под одной историей version control'а как правило -- антипаттерн (наш случай не исключение). В гите можно же в принципе креативно порезать это все с помощью submodules/subtree на более мелкие части.