Т.е., да, к CVS претензий и вопросов много. К svn поменьше, но тоже не без греха (всё же распределённые системы удобнее централизованных). Но они — системы контроля версий, пусть CVS и стрёмный, а hg/bzr/git — нет. Что-то другое. Удобное. Но с одой особенностью, которые делают их не системой поддержания истории проекта. Увы.
rebase, который не прописывается в историю. Сама идея rebase/squash/whatever хороша и иногда полезна, но это деструктивная команда, никак не отмечаемая в репозитории — ВДРУГ удалили часть коммитов бесследно. Это никак не соотносится с хранением истории проекта. Историю НЕЛЬЗЯ переписывать.
Ну и это ещё приводит к чудесным эффектам, когда такое делают у репозитория с которым кто-то уже синхронизировался. Что приводит к тому, что все “workflow” с использованием этих команд (тысячи их в интернете) неработоспособны когда одну и ту же фичу делают несколько человек или хотя бы один человек на нескольких рабочих местах (ноуте и рабочей станции или домашнем и рабочем компьютере). Но это уже побочные эффекты изначально кривого дизайна, заложенного в этих командах.
И вообще ребейз индивидуальная команда - сделал фичу один, ребейзнул и тд. Если над бранчем работает несколько человек то юзается бекмердж основного бранча а не ребейз.
reflog же. Хм. Читаю man — не вижу при чём он тут.
И вообще ребейз индивидуальная команда Это не важно. Важна сама штатная техническая возможность переписывать историю, никак не ограниченная вообще. Там хоть ACL'и нормальные появились? Или нет?
Вот если бы git сам при pull/push пользовался рефлогом (и там не было бы команды "expire") это было бы хоть на что-то похоже. А сейчас — push, ребейз, push — и репозиторий кровь кишки распидорасило а от git ни слова.
Я сам сторонник разрешения стрелять себе в ногу — но не когда речь идёт об истории, которая принципиально не должна редактироваться.
Ну гит не даст пушнуть если что-то распидорасит. Только через форс, а если ругатся на форс, то можно ругатся и на то что "rm -rf /" удалит вам все файлы в руте )
ИМХО возможность поправить историю хороша при факапе. Тогда рефлог позволяет очень гранулярно откатится куда надо и иметь чистую и читабельную историю, а не полный пиздец из-за одной ошибки.
ЗЫ: Кстати в компании мы не пользуемся рибейзом вообще, только мердж. Когда есть центральный репозиторий (гитхаб) в который feature branches регулярно пушатся, рибейз не нужен.
Ну гит не даст пушнуть если что-то распидорасит. Даст. Дабл-коммиты только так возникают если ребейзиться, пушить, снова ребейзхится и снова пушить. Что, подумав, не удивительно.
Я может туплю, но как? После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется? Если он там будет то дерево в локальном репозитории 1 ahead 1 behind и fast-forward не пройдет.
После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется? Да. А так как после второго рибейза того коммита уже нет, а есть новый (пусть и стем же сожержанием ПО СМЫСЛУ, но с другой чексуммой — т.е. идентификатором), то он снова проапушится и промёржится.
Воот! Я на это напоролся в первый же день — я использую свой сервер как точку встречи своих двух компов (итого на одного меня три репозитория — серверный и два на рабочих станциях, общение с апстримом через сервер) и, не подумав, сразу выбрал workflow с ребейзом. Потом уже подумал, хлопнул себя по лбу, и понял, что в такой схемек ребейз делать нельзя.
в svn не работают нормально feature branches. svn merge --reintegrate рассматривает обновления из trunk => feature_branch как локальные изменения бранча, и при merge --reitnergrate возникает хуева туча конфликтов. Ну о чём тут можно говорить?
И да, в svn нету бранчей, есть только папки. Папки - это не бранчи, билять.
svn merge reintegrate рассматривает обновления из trunk => feature_branch как локальные изменения бранча, и при merge reitnergrate возникает хуева туча конфликтов. Не пользуйтесь реинтегрейтом. Хотя, кажется, это чинили. FreeBSD уже немало лет живёт с фича-бранчами на свне без проблем. Конфликтов ложных нет.
И да, в svn нету бранчей, есть только папки. Папки - это не бранчи, билять. Сможешь объяснить — в чём разница? И то и то — дерево с историей и родителем (в историческом смысле родителем).
Они начиная с 1.4 это чинят. На дворе 1.7. Не работает до сих пор. Как блять на протяжении трёх версий (шести, блять ЛЕТ!) можно не сделать, наконец, мета-информацию без багов? Для меня это было основной причиной свалить на DVCS.
И да, feature branch - это 1) удобно 2) необходимое условие для нормально CI
Сможешь объяснить — в чём разница? И то и то — дерево с историей и родителем (в историческом смысле родителем). Разницы быть не должно. А вот неработающий reintegrate как бэ говорит нам, что разница на уровне метаинформации VCS таки есть, и что с такой концепцией как "бранч == папки" будет лютейший головняк.
Особенно если файлы переименовывались в бранчах. Тогда svn вообще нахуй башню сносит.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
Это которой?
no subject
Это никак не соотносится с хранением истории проекта. Историю НЕЛЬЗЯ переписывать.
Ну и это ещё приводит к чудесным эффектам, когда такое делают у репозитория с которым кто-то уже синхронизировался. Что приводит к тому, что все “workflow” с использованием этих команд (тысячи их в интернете) неработоспособны когда одну и ту же фичу делают несколько человек или хотя бы один человек на нескольких рабочих местах (ноуте и рабочей станции или домашнем и рабочем компьютере). Но это уже побочные эффекты изначально кривого дизайна, заложенного в этих командах.
no subject
И вообще ребейз индивидуальная команда - сделал фичу один, ребейзнул и тд. Если над бранчем работает несколько человек то юзается бекмердж основного бранча а не ребейз.
no subject
Хм. Читаю man — не вижу при чём он тут.
И вообще ребейз индивидуальная команда
Это не важно. Важна сама штатная техническая возможность переписывать историю, никак не ограниченная вообще. Там хоть ACL'и нормальные появились? Или нет?
no subject
Я сам сторонник разрешения стрелять себе в ногу — но не когда речь идёт об истории, которая принципиально не должна редактироваться.
no subject
ИМХО возможность поправить историю хороша при факапе. Тогда рефлог позволяет очень гранулярно откатится куда надо и иметь чистую и читабельную историю, а не полный пиздец из-за одной ошибки.
ЗЫ: Кстати в компании мы не пользуемся рибейзом вообще, только мердж. Когда есть центральный репозиторий (гитхаб) в который feature branches регулярно пушатся, рибейз не нужен.
no subject
Даст. Дабл-коммиты только так возникают если ребейзиться, пушить, снова ребейзхится и снова пушить. Что, подумав, не удивительно.
no subject
no subject
Да. А так как после второго рибейза того коммита уже нет, а есть новый (пусть и стем же сожержанием ПО СМЫСЛУ, но с другой чексуммой — т.е. идентификатором), то он снова проапушится и промёржится.
У меня без всяких форсов получилось на раз-два.
no subject
no subject
no subject
Do not rebase commits that you have pushed to a public repository. (c)
а вообще торвальдс говноед ;]
no subject
no subject
svn merge --reintegrate рассматривает обновления из trunk => feature_branch как локальные изменения бранча, и при merge --reitnergrate возникает хуева туча конфликтов.
Ну о чём тут можно говорить?
И да, в svn нету бранчей, есть только папки. Папки - это не бранчи, билять.
no subject
reintegrate рассматривает обновления из trunk => feature_branch как локальные изменения бранча, и при mergereitnergrate возникает хуева туча конфликтов.Не пользуйтесь реинтегрейтом. Хотя, кажется, это чинили. FreeBSD уже немало лет живёт с фича-бранчами на свне без проблем. Конфликтов ложных нет.
И да, в svn нету бранчей, есть только папки. Папки - это не бранчи, билять.
Сможешь объяснить — в чём разница? И то и то — дерево с историей и родителем (в историческом смысле родителем).
no subject
Как блять на протяжении трёх версий (шести, блять ЛЕТ!) можно не сделать, наконец, мета-информацию без багов?
Для меня это было основной причиной свалить на DVCS.
И да, feature branch - это 1) удобно 2) необходимое условие для нормально CI
Разницы быть не должно. А вот неработающий reintegrate как бэ говорит нам, что разница на уровне метаинформации VCS таки есть, и что с такой концепцией как "бранч == папки" будет лютейший головняк.
Особенно если файлы переименовывались в бранчах. Тогда svn вообще нахуй башню сносит.