среда, 12 ноября 2014 г.

Немного про (d)vcs и удалять ли код?

Чему меня научил git — безжалостно удалять код.

Я не замечал этого, но сегодня была необходимость посмотреть кое-что в собственном древнем коде года так 2002.

И там внезапно куча, просто куча, закомментированного о кода в стиле

/* Версия1. до рефакторинга
...

*/

Сейчас такого конечно уже не бывает — нет смысла. С какого-то момента привыкания к git проще в git log найти искомое, чем засорять код этим.

Хотя я помню и тогда уже активно пользовался cvs, и вроде бы через несколько лет уже переползал на svn.

И чувство это помню, как будто гири у тебя от ног отвязали, но все равно, по настоящему смело убивать код, и целые модули стал только в git.
Почему? Самому не понятно.

С системами контроля версий у меня длинная история, познакомился я с ними на богомерзком SourceSafe, помучился с ним годик, и затем

cvs  ➔ svn ➔ svk ➔ bzr ➔ git

Тот который cvs особенно ничем не запомнился, ну не удивительно. Я в нём merge то кажется делать не умел.

Фактически для меня это просто такой бекап был, которому я ещё и не доверял особенно.

Вот subversion уже была рабочая настоящая лошадка.
И merge, и настоящая коллективная работа, ветки, сервера и т.д.


Собственно там, вместе с ростом опыта, и понял множество проблем в совместной работе.


Сейчас конечно всё это уже дико, всё расписано в миллионах workflow, бери читай и делай.
Но тогда приходилось постоянно наступать на грабли.




С svk тоже интересная история. Сколько я себя помню, всегда был в дополнение к разработке еще и немножко админ. То что сейчас базвордом devops называют.
И поэтому всегда мне хотелось конфиги и разное такое держать под vcs.
Но для svn это был адъ. Который сейчас во многом уже исправлен, но тогда и не мечтали.

И тут я наткнулся на svk который фактически некий перл скрипт, и строит dvcs поверх subversion,  попутно решая кучу мелких проблем subversion.

Забавная штука, но в современном мире уже не нужна.

Затем bzr. После svk, когда уже идеи понятны, был плюс что реализация чуть получше, чуть попроще, но в целом об этом опыте сожалею.
Увы, потеря времени.
Зачем было брать заведомо проигрышное решение когда доступно нормальное.
Хотя мотивацию свою я помню. Начитался про то какой такой git не-человечески сложный в командах, и поверил в это.
К счастью есть протокол fastimport/fastexport который эту ошибку легко исправляет.



Немного даже завидуешь современным программистам, которые сразу могут взять себе git (а особо упоротые с синдромом мне-нужно-отличаться  mercurial) прочитать себе пару книжек про организацию workflow и сэкономить на этом годы мучений.