metaclass: (Default)
[personal profile] metaclass
Мейл-лист разработчиков некоей СУБД:
BTW, IMHO subversion is worse than CVS. I don't understand why you want to migrate at all.

Date: 2012-07-16 07:02 am (UTC)
From: [identity profile] theiced.livejournal.com
а у вас ЭТО в продакшне

Date: 2012-07-16 07:14 am (UTC)
From: [identity profile] dair-spb.livejournal.com
Я, кстати, уже не вспомню, почему мы с восторгом в начале нулевых перешли на svn, кстати. Наверно из-за кривого брэнчинга в CVS, думаю.

В SVN тоже много интересного, git ещё вменяемее, хотя тоже ыыыыы. Mercurial не жамкал, не скажу.

Date: 2012-07-16 09:12 am (UTC)
From: [identity profile] victor bolshakov (from livejournal.com)
а еще можно xcopy :)

Date: 2012-07-16 12:31 pm (UTC)
From: [identity profile] blacklion.livejournal.com
А они отличаются? По мне, так все три — git, hg, bzr — не заслуживают вообще имени системы контроля версий

Date: 2012-07-16 01:04 pm (UTC)
From: [identity profile] eternal-leave.livejournal.com
Слишком толсто

Date: 2012-07-16 01:05 pm (UTC)
From: [identity profile] blacklion.livejournal.com
А я не троллю. Я совершенно серьёзен. Да, я сам пользуюсь всеми тремя (так жизнь сложилась, что в разных проектах разные, вот и собрался зоопарк), но я совершенно искренне считаю, что это удобные инструменты -- но не системы контроля версий.

Date: 2012-07-16 01:11 pm (UTC)
From: [identity profile] blacklion.livejournal.com
Т.е., да, к CVS претензий и вопросов много. К svn поменьше, но тоже не без греха (всё же распределённые системы удобнее централизованных). Но они — системы контроля версий, пусть CVS и стрёмный, а hg/bzr/git — нет. Что-то другое. Удобное. Но с одой особенностью, которые делают их не системой поддержания истории проекта. Увы.

Date: 2012-07-16 01:35 pm (UTC)
From: [identity profile] thinker8086.livejournal.com
>> Но с одой особенностью

Это которой?

Date: 2012-07-16 01:40 pm (UTC)
From: [identity profile] blacklion.livejournal.com
rebase, который не прописывается в историю. Сама идея rebase/squash/whatever хороша и иногда полезна, но это деструктивная команда, никак не отмечаемая в репозитории — ВДРУГ удалили часть коммитов бесследно.
Это никак не соотносится с хранением истории проекта. Историю НЕЛЬЗЯ переписывать.

Ну и это ещё приводит к чудесным эффектам, когда такое делают у репозитория с которым кто-то уже синхронизировался. Что приводит к тому, что все “workflow” с использованием этих команд (тысячи их в интернете) неработоспособны когда одну и ту же фичу делают несколько человек или хотя бы один человек на нескольких рабочих местах (ноуте и рабочей станции или домашнем и рабочем компьютере). Но это уже побочные эффекты изначально кривого дизайна, заложенного в этих командах.

Date: 2012-07-16 02:22 pm (UTC)
From: [identity profile] freiksenet.livejournal.com
reflog же.

И вообще ребейз индивидуальная команда - сделал фичу один, ребейзнул и тд. Если над бранчем работает несколько человек то юзается бекмердж основного бранча а не ребейз.

Date: 2012-07-16 02:25 pm (UTC)
From: [identity profile] blacklion.livejournal.com
reflog же.
Хм. Читаю man — не вижу при чём он тут.

И вообще ребейз индивидуальная команда
Это не важно. Важна сама штатная техническая возможность переписывать историю, никак не ограниченная вообще. Там хоть ACL'и нормальные появились? Или нет?

Date: 2012-07-16 02:31 pm (UTC)
From: [identity profile] blacklion.livejournal.com
Вот если бы git сам при pull/push пользовался рефлогом (и там не было бы команды "expire") это было бы хоть на что-то похоже. А сейчас — push, ребейз, push — и репозиторий кровь кишки распидорасило а от git ни слова.

Я сам сторонник разрешения стрелять себе в ногу — но не когда речь идёт об истории, которая принципиально не должна редактироваться.

Date: 2012-07-16 02:39 pm (UTC)
From: [identity profile] freiksenet.livejournal.com
Ну гит не даст пушнуть если что-то распидорасит. Только через форс, а если ругатся на форс, то можно ругатся и на то что "rm -rf /" удалит вам все файлы в руте )

ИМХО возможность поправить историю хороша при факапе. Тогда рефлог позволяет очень гранулярно откатится куда надо и иметь чистую и читабельную историю, а не полный пиздец из-за одной ошибки.

ЗЫ: Кстати в компании мы не пользуемся рибейзом вообще, только мердж. Когда есть центральный репозиторий (гитхаб) в который feature branches регулярно пушатся, рибейз не нужен.

Date: 2012-07-16 02:43 pm (UTC)
From: [identity profile] blacklion.livejournal.com
Ну гит не даст пушнуть если что-то распидорасит.
Даст. Дабл-коммиты только так возникают если ребейзиться, пушить, снова ребейзхится и снова пушить. Что, подумав, не удивительно.

Date: 2012-07-16 02:51 pm (UTC)
From: [identity profile] freiksenet.livejournal.com
Я может туплю, но как? После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется? Если он там будет то дерево в локальном репозитории 1 ahead 1 behind и fast-forward не пройдет.

Date: 2012-07-16 02:54 pm (UTC)
From: [identity profile] blacklion.livejournal.com
После второго рибейза в репозитории куда пушим будет коммит посде предыдущего рибейза, куда он денется?
Да. А так как после второго рибейза того коммита уже нет, а есть новый (пусть и стем же сожержанием ПО СМЫСЛУ, но с другой чексуммой — т.е. идентификатором), то он снова проапушится и промёржится.

У меня без всяких форсов получилось на раз-два.

Date: 2012-07-16 02:59 pm (UTC)
From: [identity profile] freiksenet.livejournal.com
Блядь, и правда. Правильно мы всегда мёрдж юзаем тогда %)

Date: 2012-07-16 03:00 pm (UTC)
From: [identity profile] blacklion.livejournal.com
Воот! Я на это напоролся в первый же день — я использую свой сервер как точку встречи своих двух компов (итого на одного меня три репозитория — серверный и два на рабочих станциях, общение с апстримом через сервер) и, не подумав, сразу выбрал workflow с ребейзом. Потом уже подумал, хлопнул себя по лбу, и понял, что в такой схемек ребейз делать нельзя.

Date: 2012-07-17 12:21 am (UTC)
From: [identity profile] theiced.livejournal.com
так делать низяяяяя.

Do not rebase commits that you have pushed to a public repository. (c)

а вообще торвальдс говноед ;]

Date: 2012-07-16 04:17 pm (UTC)
From: [identity profile] http://users.livejournal.com/_slw/
распределенный svn называется svk

Date: 2012-07-17 09:43 am (UTC)
From: [identity profile] zamotivator.livejournal.com
в svn не работают нормально feature branches.
svn merge --reintegrate рассматривает обновления из trunk => feature_branch как локальные изменения бранча, и при merge --reitnergrate возникает хуева туча конфликтов.
Ну о чём тут можно говорить?

И да, в svn нету бранчей, есть только папки. Папки - это не бранчи, билять.

Date: 2012-07-17 09:59 am (UTC)
From: [identity profile] blacklion.livejournal.com
svn merge reintegrate рассматривает обновления из trunk => feature_branch как локальные изменения бранча, и при merge reitnergrate возникает хуева туча конфликтов.
Не пользуйтесь реинтегрейтом. Хотя, кажется, это чинили. FreeBSD уже немало лет живёт с фича-бранчами на свне без проблем. Конфликтов ложных нет.

И да, в svn нету бранчей, есть только папки. Папки - это не бранчи, билять.
Сможешь объяснить — в чём разница? И то и то — дерево с историей и родителем (в историческом смысле родителем).

Date: 2012-07-17 10:03 am (UTC)
From: [identity profile] zamotivator.livejournal.com
Они начиная с 1.4 это чинят. На дворе 1.7. Не работает до сих пор.
Как блять на протяжении трёх версий (шести, блять ЛЕТ!) можно не сделать, наконец, мета-информацию без багов?
Для меня это было основной причиной свалить на DVCS.

И да, feature branch - это 1) удобно 2) необходимое условие для нормально CI

Сможешь объяснить — в чём разница? И то и то — дерево с историей и родителем (в историческом смысле родителем).
Разницы быть не должно. А вот неработающий reintegrate как бэ говорит нам, что разница на уровне метаинформации VCS таки есть, и что с такой концепцией как "бранч == папки" будет лютейший головняк.

Особенно если файлы переименовывались в бранчах. Тогда svn вообще нахуй башню сносит.
Edited Date: 2012-07-17 10:04 am (UTC)

Date: 2012-07-16 09:13 am (UTC)
From: [identity profile] victor bolshakov (from livejournal.com)
Это которая Firebird?

Date: 2012-07-16 09:14 am (UTC)
From: [identity profile] tzirechnoy.livejournal.com
Да ну, херня про worse. Я активно пользовался и тем и тем -- SVN заметно удобнее.

Date: 2012-07-16 01:06 pm (UTC)
From: [identity profile] kiryl.livejournal.com
Как известно, SVN -- это тот же CVS только лучше. Поскольку CVS -- говно, SVN -- ещё говнистей.

Date: 2012-07-16 12:24 pm (UTC)
From: [identity profile] ilya-portnov.livejournal.com
CVS cannot be done right же.

Date: 2012-07-16 01:01 pm (UTC)
From: [identity profile] migmit.livejournal.com
У нас был CVS ещё полгода назад. С тех пор наша группа перешла на TFS, но многие другие остались на CVS. Поддержание консистентности этой связки - особая тема.

Date: 2012-07-16 06:26 pm (UTC)
From: [identity profile] siaržuk piatroŭski (from livejournal.com)
Калі ў нас адбываўся пераход на GIT з SVN, я таксама казаў, што git is worse than svn. :-)

Date: 2012-07-16 06:53 pm (UTC)
From: [identity profile] firebie.livejournal.com
svn на сервере, git локально. Удобно, и история на сервере не переписывается.

Date: 2012-07-16 06:58 pm (UTC)
From: [identity profile] metaclass.livejournal.com
Да, подобным образом mercurial использую.

Profile

metaclass: (Default)
metaclass

April 2017

S M T W T F S
      1
2345678
9101112 131415
16171819202122
23242526272829
30      

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 9th, 2025 09:38 pm
Powered by Dreamwidth Studios