Я в понедельник приду на работу, а там вместо CVS - Perforce. Как оно полетит, я не знаю, но слышал, что к нему есть возможность обращаться через git-интерфейс, который мне попривычнее будет. Это правда?

там есть какая-то git приставка, но что она детально даёт - я не знаю, т.к. не использовал ни разу и пока руки не дошли поглядеть.

с виду - полная дичь, т.к. даёт локально git-repository, а на perforce уже закидывает версии в его собственную структуру. Но, может, от этого толк и есть, наскоро судить не берусь.

Мне нравится двухступенчатая система - можно в свой репозиторий делать несколько коммитов, а потом их сплющить и послать в базу как один.

а чем это принципиально лучше, чем если делать несколько коммитов на одну ветку, а потом всё разом замерджить в другую?

Зачем засорять основную базу?

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

Вся беда этих CVS и последовавших за ним SVN & P4 в том, что их ветки, если активно используются отдельными разработчиками, действительно засоряют систему, а дерево версий обозрению во вменяемое время не подлежит ни в целом, ни даже в отдельных частных подробностях.

Мне казалось, что деревья в Git должны быть компактными и вменяемыми, впрочем я их пока не видел )))

деревья в Git должны быть компактными и вменяемыми

Welcome to the "merge" vs "rebase" controversy. Если по привычке говорить merge, то даже при трех людях, редактирующих одни и те же файлы, дерево достаточно быстро превратится в развесистый куст. Некоторых (не меня) это сильно раздражает.

а вот не надо делать rebase. и не надо делать merge с главной ветки на девелоперскую... Поработал, сделал фичу, замерджил в главную ветку.

Мечты, мечты...

но всё же, по первым прикидкам, я очень надеюсь, что в Git есть достаточно много операций, когда дерево при практической работе не портится столь радикально, как оно портится в P4, SVN, ClearCase UCM.

На p4 тут вообще без слёз смотреть нельзя - каждый девелопер, открывающий собственную ветку, сразу же модифицирует дерево каждого файла. И эта ветка растёт при каждом мердже-ребейзе. Просто натуральное вредительство.

Это, IMO, доказывает вред понятия "девелоперская ветка". У нас разработка обычно делается в главной ветке, а побочные образуются при feature freeze и пополняются багфиксами. Ветки для разработки бывают лишь в случаях предполагаемых ветвлений релизов.

если система позволяет делать ветки красивыми - вполне можно делать девелоперские ветки. Я так работал под clearcase пару лет лет так... 12 назад и наслаждался жизнью )))

С тех пор и вынес убеждение, что ветки должно быть позволено делать каждому и столько сколько нужно, но дерево ДОЛЖНО быть красивым - иначе игра не стоит свеч. Красивость, разумеется, обеспечивает правильная конструкция системы, а не кропотливая работа программиста или администратора.

Я работал под Clearcase лет 17-18 назад, и тогда он требовал администратора на полной ставке, иначе всё очень быстро шло прахом. А программисты под Clearcase при квалифицированном администраторе наслаждаются жизнью, да.

так я и не говорю, что Clearcase вообще идеален во всём. Но, во всяком случае, постоянный администратор был платой совсем не только за структуру веток ClearCase, хотя и за нее отчасти тоже.

Мне кажется, что достаточно и пары квалифицированных пользователей, чтобы организовать работу на ClearCase, но я понятия не имею о полном объеме административных задач (что может включать в себя и бекапы, и восстановление повреждений и реплиацию между серверами и чего еще только нет)

а как вам нравится работать с "index" в git?

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

я не прав?

Если честно, индустриально git-ом я не пользовался; только для хобби-проектов, так что это меня утомить не успело, а вот то, что perforce по умолчанию требует открывать каждый файл на запись, кажется странным, хотя и понятно, что при отсутствии локальной копии репозитория это необходимая дань производительности.

* perforce по умолчанию требует открывать каждый файл на запись

я работал и так (под SVN) и так (подо всем остальным), даже и не знаю что тут лучше.