разочарования

[netch80]

- Функция loop получает кучу параметров, внутри неё if, и только в одной ветке
надо поменять значение одного параметра, а в остальные он должен прийти
неизменённым. Как это удобно сделать?
- Вызови в этом месте loop() с новым параметром и заверши работу.
- Но у меня дальше большая общая часть работы.
- Вынеси её в отдельную функцию, вызови loop() из неё.
- Это неудобно. Почему бы не сделать что-то вроде Xout=ifdef(X1, X1, X),
loop(...,Xout)?
- Ты хочешь неправильного. Здесь делают именно так.

---

- Как это нормально делается? Я же не могу отдать параметр обратно.
- Сложи его значение в ets.
- Но это уже побочный эффект, это неправильная практика. Надо избавляться
от побочных эффектов.
- Здесь делают так.
- Но ets дорого, и неуникально. Я не могу изобретать атом для каждого
процесса, они плодятся по одному для внешнего объекта согласно конфигурации.
Почему бы не использовать словарь процесса?
- Это неправильно. Словарь процесса - костыль, его скоро отменят.
- Но ets - такой же костыль, причём менее удобный, потому что надо использовать
левые сущности вроде имён-атомов.
- Здесь делают так.
- Почему я не могу использовать в качестве идентификатора таблицы текстовую
строку?
- Здесь так не принято.

---

- Мне нужно сделать общий репозиторий, в который все будут складывать свои
изменения.
- Ты хочешь неправильно. Это распределённая система.
- Я и использую её как распределённую. Каждый тащит изменения к себе, делает
что хочет в любом количестве своих копий и репозиториев, затем, когда решил,
что всё окончательно правильно - делает push.
- Ты хочешь неправильно. Каждый должен коммитить в свою ветку в центральном
репозитории. Дальше у него остальные забирают изменения.
- Я не хочу разводить бардак, особенно когда таких источников будет два
десятка. Каждый обязан влить свои изменения и за это отвечает.
- Ты хочешь неправильно. Здесь так не делают. Приходи, получай ченжсеты
от своих сотрудников и вливай это в общий репозиторий, есть стандартная
поддержка приёма и применения по почте и иными средствами.
- Мне надо чтобы они это делали сами. И это неудобно ещё по целому ряду
параметров - например, надо держать на сервере полный шелл.
- Ты хочешь неправильно. Это распределённая система.

---

- Если я хочу один репозиторий, но две рабочих копии?
- Ты хочешь неправильно. Это распределённая система. Каждая рабочая копия
получает полную копию репозитория со всей историей.
- Я не хочу каждый раз переливать между двумя репозиториями у себя в home.
- Ты хочешь неправильно. Это распределённая система.

---

- Лог коммитов сортируется по дате исходного коммита. Если кто-то поставил
дату коммита 70-м годом, его будет очень долго и нудно искать.
- Да, дата коммита и авторство не меняются при слиянии.
- Тогда почему у коммита нет нескольких дат и авторов? Ведь тот, кто влил
набор изменений, тоже сделал существенное действие, которое должно быть
отражено. Он выбрал источник вливания, он выбрал набор изменений.
- Ты хочешь странного.

Comments

[blacklion.livejournal.com]

\\- Мне нужно сделать общий репозиторий, в который все будут складывать свои
изменения.\\
Как же я не люблю распределённые системы…

У нас вообще дерево репозиториев — ГЛАВНОЕ (Release Engenerring'овое), потом по крупным кускам, потом по командам внутри кусков. В каждой команде есть человек (ротируется раз в месяц, все сидят на этой должности по очереди), который раз в неделю вс изменения команды отправляет наверх, дожидается пока изменения других команд тоже будут отправлены наверх и спускает их вниз, в резпозиторий своей команды.

Жуть.

[netch80.livejournal.com]

Ну мы в итоге сделали - каждому свой логин под общим uid и это всё через ssh.
Изврат, конечно, зверский. Зато пропала необходимость каждый день восстанавливать содержимое .git/refs/heads/master.

[blacklion.livejournal.com]

Не, у нас всё true-distributed… На своих фермах серверных, и прочее. И, да, репозиторий в ~ на каждый баг и фичу.

[blacklion.livejournal.com]

Плюс — у нас ДЕРЕВО ЛЕСОВ (используется расширение forest), т.е. репозиторий сам собирается из кусков расширением forest и такие сборные репозитории выстроены в дерево отношением родитель-потомок… Ужос.

Вообще, зачем ВАМ hg, а не subversion, когда один центральный репозиторий, который видят все, — плохо понятно. “Тут так принято”? На мой вкус, hg изрядно ещё сыр.

[netch]

У нас git, а не hg. Был взят потому, что второй отдел пилит рашпилем дистрибутив, у которого рабочий процесс на git.

[sha90w.livejournal.com]

эт они Alt что ли пилят...

[netch]

В общем да.

[blacklion.livejournal.com]

А ты что, из админов в ерланг-программисты перешёл?

[netch80.livejournal.com]

Дык. Только сам не пишу (пока?), руковожу группой.

[blacklion.livejournal.com]

Круто. Хоть и с разочарованиями.

[p1r4nh4.livejournal.com]

> - Если я хочу один репозиторий, но две рабочих копии?

http://www.selenic.com/mercurial/wiki/index.cgi/SharedRepoExtension

[netch]

Дяденька, мне под фряху git!

[p1r4nh4.livejournal.com]

Я понимаю, но может там можно что-то подобное сделать? :) Ну и "здесь так не принято" - это тупо отмазка, потому что все замечания по поводу dvcs к тому, как работаем мы, не относится.

У нас один общий репозиторий (когда много разработчиков, то не все могут пушить, а просто делятся на небольшие группки - для стройности, но это по желанию). Я юзал и N рабочих копий - один репо, и наоборот (N репозиториев - 1 рабочая копия), ну и уж тем более в хг такой глупостью, как сортировка по дате, и не пахнет.

[alexott.livejournal.com]

git clone --shared/--local ?

[sha90w.livejournal.com]

Показал одному знакомому программирующему на Erlang (известному в узких кругах) - похоже, что
ты прав, а то у вас локальные заморочки:

цитирую:
"если словарь процесса действительно лучшее решение, то не вижу причин его не поюзать
словарь процесса совершенно точно никто не отменит
XOut = if ... -> X; ... -> X1 end -- это обычная практика"

по поводу таблиц - действительно ets таблицы либо по номеру, либо по атому идентифицируются.

[netch]

А точный текст примера этого if можно получить?

[sha90w.livejournal.com]

ну вот что-нить такое
loop(A, B, C, X) ->
XOut = if
A > B -> ..., X;
B > C -> ..., X;
true -> ..., A + B + C
end,
...,
loop(A, B, C, XOut).

A + B + C + X лучше

[sha90w.livejournal.com]

несколько исправленный вариант:

loop(A, B, C, X) ->
   XOut = if
             A > B -> ..., X;
             B > C -> ..., X;
             true -> ..., A + B + C + X
          end,
   ...,
   loop(A, B, C, XOut).

[egorfine.livejournal.com]

git и другие распределенные системы требуют компостировки мозга. Как только мозг проткнулся в нужном месте - все становится на места и понятно.

Мы перешли на git c svn'а примерно полторы недели назад и компостировка далась хоть и с трудом, но безболезненно. Зато теперь девелоперы творят всякие трюки типа "Гоша, я вот тут написала эту регистрацию, давай я ее тебе пушну, ты смерджишь с роутерами и пушнешь мне назад?"

[netch80.livejournal.com]

Неее, дядьку, вы мозги НЕ докомпостировали:)) Потому что у вас тогда не было бы "пушнуть другому" в принципе, а должно быть только "пульни из меня из ветки XX"

[egorfine.livejournal.com]

ну пульнул, а потом что? а потом пуш обратно:)

[netch80.livejournal.com]

Нет!! Никак не "обратно". Или по email всем остальным, или в _свою_ ветку в "центральном" репозитории, откуда все остальные делают pull, чтобы принять твои изменения.

Я удивлялся так же как и ты сейчас, когда мне это доказывали два дня подряд:))

[egorfine.livejournal.com]

Фишка гита в том, что он позволяет тебе самому выбирать тот процесс, который ты считаешь нужным. Есть рекомендации и их писали умные люди, и имеет смысл прислушиваться. Но есть также и твой собственный проект, где имеют место быть твои собственные правила и практики:)

[netch80.livejournal.com]

push, если это не git-server, требует дурной игры с правами доступа. На многопользовательский push система просто не рассчитана. Так что не позволяет он тебе настолько выбирать процесс... или позволяет только с дурными костылями.

[egorfine.livejournal.com]

Какие костыли? g+w у каждого и досвидания. Все просто как в юниксе.

[netch80.livejournal.com]

Ладно, перепроверю. У нас могло наложиться на еженощный кроновый gc.

[anatoly borodin (from livejournal.com)]

у вас там так много мусора накапливается?

[netch80.livejournal.com]

Вспомнил на перечитке. g+w недостаточно. Оно регулярно создаёт новые файлы и не ставит на них адекватные права. Даже umask не сработал (или скриворучили).

В общем, сейчас работает под общим uid'ом.

[egorfine.livejournal.com]

мы решили так:

* * * * * chgrp -R git /var/git; chmod -R g+w /var/git/

[antimirov.livejournal.com]

Это в Порте теперь Ерланг? Гы...

[netch80.livejournal.com]

В Порте он будет через год, если подсуечусь:) Это - на новом месте