факапы на работе
От: HoseCo  
Дата: 04.04.17 13:37
Оценка: +2
Здрасте.

Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?
Re: факапы на работе
От: turbocode  
Дата: 04.04.17 13:40
Оценка:
HC>Тут у нас программист один случайно похерил результаты своей недели работы.

Интересно как? Ведь можно же комитить в свою ветку.
Re[2]: факапы на работе
От: HoseCo  
Дата: 04.04.17 13:41
Оценка:
Здравствуйте, turbocode, Вы писали:

T>Интересно как? Ведь можно же комитить в свою ветку.


похоже не комитил
Re[3]: факапы на работе
От: turbocode  
Дата: 04.04.17 13:50
Оценка: +1 -3
T>>Интересно как? Ведь можно же комитить в свою ветку.
HC>похоже не комитил

Тогда правильно что заставляют и это не будет оплачено.
Re: факапы на работе
От: Shmj Ниоткуда  
Дата: 04.04.17 13:52
Оценка: +7 -1
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


Если нет репозитория и порядка ежедневных (минимум) коммитов -- виновата контора.

Если репозиторий есть и требования есть, но он по своей халатности коммитов не делал -- виноват работник. Либо пусть работает сверхурочно, либо лишить премии.
Re: факапы на работе
От: ry Россия  
Дата: 04.04.17 14:15
Оценка: +1
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.

И Вам не хворать.

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Что же в этом нормального. Пацан должен сам впереди паровоза бежать, лишь бы всё восстановить.
Re[2]: факапы на работе
От: HoseCo  
Дата: 04.04.17 14:15
Оценка: +6
Здравствуйте, Shmj, Вы писали:

S>Если репозиторий есть и требования есть, но он по своей халатности коммитов не делал -- виноват работник. Либо пусть работает сверхурочно, либо лишить премии.


По своей халатности. Вот лишить премии, если премии вообще бывают, по мне норм решение. А вот отрабатывать сверхурочно без оплаты мне как-то кажется ну соовсем не по человечески. Да и сомневаюсь что с ТК это как-то согласуется.
Re[2]: факапы на работе
От: lpd Черногория https://vk.com/rashchupkinr
Дата: 04.04.17 14:30
Оценка: +5
Здравствуйте, Shmj, Вы писали:

S>Если нет репозитория и порядка ежедневных (минимум) коммитов -- виновата контора.


Никогда не встречал порядка ежедневных коммитов в договоре. Тогда должно быть прописано и что делать в случае потери кода.

S>Если репозиторий есть и требования есть, но он по своей халатности коммитов не делал -- виноват работник. Либо пусть работает сверхурочно, либо лишить премии.


Риски ошибок работников или других случайностей всегда существуют, и в большинстве случаев лежат на работодателе. Сверхурочные уместны только если это особенно срочная работа. Разовая потеря кода сама по себе даже не говорит о недостаточной квалификации работника.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Отредактировано 04.04.2017 14:36 lpd . Предыдущая версия .
Re[3]: факапы на работе
От: sharpcoder Россия  
Дата: 04.04.17 14:48
Оценка: :)))
Здравствуйте, HoseCo, Вы писали:

HC>Здравствуйте, Shmj, Вы писали:


S>>Если репозиторий есть и требования есть, но он по своей халатности коммитов не делал -- виноват работник. Либо пусть работает сверхурочно, либо лишить премии.


HC>По своей халатности. Вот лишить премии, если премии вообще бывают, по мне норм решение. А вот отрабатывать сверхурочно без оплаты мне как-то кажется ну соовсем не по человечески. Да и сомневаюсь что с ТК это как-то согласуется.


А по закону за это даже посадить можно, если доказать значительный ущерб для работодателя.

Это из УК:

"Халатность, то есть неисполнение или ненадлежащее исполнение должностным лицом своих обязанностей вследствие недобросовестного или небрежного отношения к службе либо обязанностей по должности, если это повлекло причинение крупного ущерба...
наказывается штрафом в размере до ста двадцати тысяч рублей или в размере заработной платы или иного дохода осужденного за период до одного года, либо обязательными работами на срок до трехсот шестидесяти часов, либо исправительными работами на срок до одного года, либо арестом на срок до трех месяцев."


Либо в рамках ТК материальная ответственность на всю сумму причиненного ущерба, включая З.П., стоимость аренды и т.п. В случае с нематериальным активом доказать сложно.
Re[3]: факапы на работе
От: Kernan Ниоткуда https://rsdn.ru/forum/flame.politics/
Дата: 04.04.17 15:21
Оценка: +1
Здравствуйте, HoseCo, Вы писали:


HC>похоже не комитил

Коммитил, но не пушил в origin.
Sic luceat lux!
Re: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 15:32
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


1. Это незаконно
2. У вас нет сорсконтрола?
Re[2]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 15:36
Оценка:
Здравствуйте, Shmj, Вы писали:

S>Если нет репозитория и порядка ежедневных (минимум) коммитов -- виновата контора.


Ежедневные — это как-то странно. Бывает, что в день пять законченных кусочков сделаешь, и, естественно, сразу закоммитишь. А бывает, что кусок сложный, и на законченные простые его не разобьешь. Что, так и коммитить в конце дня в том полуразобранном состоянии, в котором оно к концу дня оказалось?

Но требование регулярных коммитов я всячески одобряю и поддерживаю.

S>Если репозиторий есть и требования есть, но он по своей халатности коммитов не делал -- виноват работник. Либо пусть работает сверхурочно, либо лишить премии.


По закону нельзя заставить работать сверхурочно.
Re[4]: факапы на работе
От: Kesular  
Дата: 04.04.17 16:26
Оценка: +3 -2
Здравствуйте, turbocode, Вы писали:

T>Тогда правильно что заставляют и это не будет оплачено.


Неправильно, надо было просто уволить. Как вообще можно писать код и не коммитить?
Re: факапы на работе
От: Dziman США http://github.com/Dziman
Дата: 04.04.17 16:27
Оценка: +3
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


— Где курсовая?
— Писал не отрываясь три недели, а вчера собака съела.

Как-то непрофессионально как минимум. Но заставлять отрабатывать сверхурочно, наверное, уже слишком.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[3]: факапы на работе
От: sharpman Россия  
Дата: 04.04.17 16:40
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>По закону нельзя заставить работать сверхурочно.


В гите — временная репа
В ТФС — полка
.

Пессимисты говорят, что хуже быть не может,
а оптимисты всегда уверены, что — может!

.

Re: факапы на работе
От: Gattaka Россия  
Дата: 04.04.17 16:46
Оценка: +1 :))
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Рекомендую вам бежать с этой конторы. Все что вы описали выше говорит о плохо поставленном процессе разработки. Как такое могло получиться? Он ведь каждый день на статусе рассказывает что сделал вчера. За неделю это он 5 раз что-то рассказывал. Тимлид просматривает коммиты каждый день. Тимлид что не видел что у чувака коммитов нет? Если у чувака важная работа или он чувак с повышенным риском. То почему он свою работу делал один? Где напарник?
Кроме плохо поставленных процессов из описанного выше понятно, что у вас есть менеджер и он решил от парнишки избавиться. Чтобы тот сам ушел. Вполне вероятно, что настрой менеджера изменится и он возьмется за вас.
Re[3]: факапы на работе
От: Sharov Россия  
Дата: 04.04.17 17:32
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Но требование регулярных коммитов я всячески одобряю и поддерживаю.


Угу, вроде коллективный фаулер советует коммитить часто в течение рабочего дня, а в конце делать push в соотв. ветку.
Кодом людям нужно помогать!
Re[4]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 17:49
Оценка: +5
Здравствуйте, Sharov, Вы писали:

Pzz>>Но требование регулярных коммитов я всячески одобряю и поддерживаю.


S>Угу, вроде коллективный фаулер советует коммитить часто в течение рабочего дня, а в конце делать push в соотв. ветку.


Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?
Re[5]: факапы на работе
От: Sharov Россия  
Дата: 04.04.17 18:01
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Sharov, Вы писали:


Pzz>>>Но требование регулярных коммитов я всячески одобряю и поддерживаю.


S>>Угу, вроде коллективный фаулер советует коммитить часто в течение рабочего дня, а в конце делать push в соотв. ветку.


Pzz>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?


Если это branch в котором только Вы работаете, то по любому push'ить.
Кодом людям нужно помогать!
Re: Мой исходный код съел кот Мурзик
От: rm822 Россия  
Дата: 04.04.17 18:05
Оценка:
HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

The Pragmatic Programmer

From Journeyman to Master


Глава 1.1 Принятие ответственности
...
"Если жесткий диск выходит из строя, унося в небытие весь исходный текст, а у вас
нет резервной копии, это ваша вина. Фраза "Мой исходный текст съел кот Мурзик",
высказываемая вашему шефу, не решит возникшей проблемы."



http://ideafix.name/wp-content/uploads/stuff/book51.pdf
Re[6]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 18:16
Оценка: +2
Здравствуйте, Sharov, Вы писали:

Pzz>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?


S>Если это branch в котором только Вы работаете, то по любому push'ить.


Звучит, как религиозная догма.
Re[7]: факапы на работе
От: Sharov Россия  
Дата: 04.04.17 18:27
Оценка: +1
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Sharov, Вы писали:


Pzz>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?


S>>Если это branch в котором только Вы работаете, то по любому push'ить.


Pzz>Звучит, как религиозная догма.


А в чем проблема в случае отдельной ветки? Ну будет поломанная версия, но как бэ никто не должен ее трогать помимо...
Кодом людям нужно помогать!
Re: факапы на работе
От: 0x7be СССР  
Дата: 04.04.17 18:33
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать.

HC>Меня что-то от этого прям корежит.
Правильно корёжит.

HC>Как считаете это норм?

Не норм и против закона.
Re[8]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 18:35
Оценка: +1
Здравствуйте, Sharov, Вы писали:

S>А в чем проблема в случае отдельной ветки? Ну будет поломанная версия, но как бэ никто не должен ее трогать помимо...


Я стараюсь придерживаться того правила, что коммит не должен делать хуже, чем было. Т.е., я могу, например, закоммитить кусок неработающего кода при условии, что он 1) собирается 2) к нему пока нет обращений. Но я не буду делать коммит, который что-нибудь ломает (в смысле, мне известно, что он что-нибудь ломает; пропущенные ошибки — это отдельная история), даже в отдельную ветку.
Re[9]: факапы на работе
От: Dziman США http://github.com/Dziman
Дата: 04.04.17 18:47
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Sharov, Вы писали:


S>>А в чем проблема в случае отдельной ветки? Ну будет поломанная версия, но как бэ никто не должен ее трогать помимо...


Pzz>Я стараюсь придерживаться того правила, что коммит не должен делать хуже, чем было. Т.е., я могу, например, закоммитить кусок неработающего кода при условии, что он 1) собирается 2) к нему пока нет обращений. Но я не буду делать коммит, который что-нибудь ломает (в смысле, мне известно, что он что-нибудь ломает; пропущенные ошибки — это отдельная история), даже в отдельную ветку.

А в чем проблем сломанной ветки если над ней работает эксклюзивно один разработчик? Потерянные Х дней работы лучше?
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[10]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 19:10
Оценка:
Здравствуйте, Dziman, Вы писали:

D>А в чем проблем сломанной ветки если над ней работает эксклюзивно один разработчик?


Меня нервирует сломанная ветка в репозитории.

D>Потерянные Х дней работы лучше?


Не знаю, не пробовал
Re: факапы на работе
От: bazis1 Канада  
Дата: 04.04.17 19:22
Оценка: +3
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

ИМХО, сильно зависит от обстоятельств. Одно дело — полетел диск, или сгорел компьютер. Другое дело — сам по ошибке удалил, или по собственной глупости затеял какой-нибудь большой апдейт, или переустановку, не сделав бэкапы.
Но в выходные выходить — это перебор. В бизнесе обычно риски лежат на том, кому достается прибыль. И требовать компенсаций с сотрудника на зарплате — перебор. Ну уволить — самое оно. Особенно если сотрудник — один из тех, у которых все вечно не получается, но на каждый случай готов миллион железных оправданий.
Re[5]: факапы на работе
От: John1979  
Дата: 04.04.17 19:40
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

есть мнение, что ситуация, когда у тебя 3 дня лежит код который даже не собирается, не очень нормальна.
Re[2]: факапы на работе
От: sharpcoder Россия  
Дата: 04.04.17 20:04
Оценка: -1
Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, HoseCo, Вы писали:


HC>>Здрасте.


B>Но в выходные выходить — это перебор. В бизнесе обычно риски лежат на том, кому достается прибыль. И требовать компенсаций с сотрудника на зарплате — перебор.


Что за фантазии?
В бизнесе риски всегда на получателе денег, а не на плательщике.
Конечно, наемные работники поивыкли к подходу "я ни за что не отвечаю", но этот подход ошибочный.
Закон предусматривает очень много разной ответственности за факапы, от компенсации ущерба в размере месячной зарплаты (а для этого даже суд не нужен), до компенсации в полном объеме и даже уголовка — если ущерб крупный.

Другое дело, что практики применения всего этого особенно нет (я не слышал).

B>Ну уволить — самое оно. Особенно если сотрудник — один из тех, у которых все вечно не получается, но на каждый случай готов миллион железных оправданий.


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

http://base.garant.ru/12125268/39/#friends
Re[3]: факапы на работе
От: John1979  
Дата: 04.04.17 20:29
Оценка:
Здравствуйте, sharpcoder, Вы писали:

S>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.

S>http://base.garant.ru/12125268/39/#friends
и много людей ты уже поштрафовал ?
Re[3]: факапы на работе
От: bazis1 Канада  
Дата: 04.04.17 21:17
Оценка: 10 (2) +2
Здравствуйте, sharpcoder, Вы писали:

S>Что за фантазии?

Это не фантазии, это принятие реальности. Думаешь мне эта ситуация нравится?
S>В бизнесе риски всегда на получателе денег, а не на плательщике.
В общем случае — да. Но трудовые отношения — это отдельная сильно зарегулированная тема.
S>Конечно, наемные работники поивыкли к подходу "я ни за что не отвечаю", но этот подход ошибочный.
S>Закон предусматривает очень много разной ответственности за факапы, от компенсации ущерба в размере месячной зарплаты (а для этого даже суд не нужен), до компенсации в полном объеме и даже уголовка — если ущерб крупный.
Ты забываешь, что рынок труда — это такой же рынок, как и остальные. Если подобные вещи пытаться по всей строгости применять, то к тебе просто работать никто не пойдет. Потому что за углом за ту же зарплату котики, печеньки и nine to five.
Плюс, менеджмент же. Если человек — обычный винтик, то закрыв глаза на факап (и правильно это обыграв) ты получишь лояльного сотрудника, которому можно в долгосрочной перспективе меньше платить. Если он хороший спец — то все равно второго такого искать дороже. В общем, от прямой конфронтации обычно проигрывают все, за исключением эго конфронтирующего.

S>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.

S>http://base.garant.ru/12125268/39/#friends
По твоей же ссылке:

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

Под прямым действительным ущербом понимается реальное уменьшение наличного имущества работодателя или ухудшение состояния указанного имущества (в том числе имущества третьих лиц, находящегося у работодателя, если работодатель несет ответственность за сохранность этого имущества), а также необходимость для работодателя произвести затраты либо излишние выплаты на приобретение, восстановление имущества либо на возмещение ущерба, причиненного работником третьим лицам.

С недописанным софтом замучаешься доказывать. Ну заявит работник, что имущество (софт) хранилось на оборудовании работодателя и было утеряно вследствие дефекта оборудования (баг FS). И все, приплыли. Если нет четких письменных должностных инструкций, где прописано, что куда и как часто бэкапить, то с работника спроса нет.

P.S. Мне все вышеописанное не нравится, но практика показывает, что подход "я работник, я решаю производственные задачи в обмен на кэш, и оставляю эмоции, интриги и чувства за порогом" в реальном мире не работает, как бы мне не хотелось обратного.
Re[6]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 04.04.17 21:21
Оценка: +6
Здравствуйте, John1979, Вы писали:

Pzz>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

J>есть мнение, что ситуация, когда у тебя 3 дня лежит код который даже не собирается, не очень нормальна.

Не всякую работу можно разбить на кусочки по полчаса.
Re: факапы на работе
От: Artem Korneev США https://www.linkedin.com/in/artemkorneev/
Дата: 05.04.17 00:28
Оценка: +2
Здравствуйте, HoseCo, Вы писали:

HC> Как считаете это норм?


Не норм. Ещё не родился тот программист, что не косячил бы хотя бы изредка.

Чтобы не было таких крупных факапов, нужно что-то менять в процессе. Если код ежедневно не коммитится в ветки разработчиков, то любые результаты работы более чем одного дня должны попадать или в код ревью или каким-то боком в систему контроля версий. В кривых системах вроде TFS есть "shelveset'ы", где можно просто сохраниться как есть. Git и прочие позволяют заводить ветки для каждого сотрудника.

Человека — понять и простить. Он, наверное, и так уже все волосы на заднице выдрал от досады. Ну можно премию покоцать.
С уважением, Artem Korneev.
Re: факапы на работе
От: Serg27  
Дата: 05.04.17 03:44
Оценка: 5 (1) +1
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


Виноват системный администратор, который не наладил ежедневный бэкап на рабочих машинах и не проверил что он работает. Хорошо бы также проверить какие его действия будут в случае поломки диска на сервере и через сколько времени можно будет начать нормально работать всей организации.
Вообще этот случай указывает на серьезные проблемы в организации работы. Как технические, так организационные. То что всю вину хотят "списать" на работника — тоже показатель. Т.е. реальные проблемы решать не умеют/не хотят, а только прикрывают свою задницу.
Да даже и если работник полная бестолочь — это недоработка тех кто его нанимал и до сих пор не избавился.
Отредактировано 05.04.2017 10:56 Serg27 . Предыдущая версия .
Re[5]: факапы на работе
От: GarryIV  
Дата: 05.04.17 04:32
Оценка: -9 :)
Здравствуйте, Pzz, Вы писали:

S>>Угу, вроде коллективный фаулер советует коммитить часто в течение рабочего дня, а в конце делать push в соотв. ветку.


Pzz>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?


Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.
WBR, Igor Evgrafov
Re: факапы на работе
От: Alexander G Украина  
Дата: 05.04.17 04:41
Оценка: +2
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


Время занимает проектирование, отладка, выбор одного оптимального варианта из нескольких, изучение незнакомых АПИ, и т.д., а не сам набор кода.
Ну то есть, утраченные изменения за неделю должны восстанавливаться не более, чем за день, их просто снова набрать.
Русский военный корабль идёт ко дну!
Re[4]: факапы на работе
От: HoseCo  
Дата: 05.04.17 06:09
Оценка:
Здравствуйте, sharpcoder, Вы писали:

S>А по закону за это даже посадить можно, если доказать значительный ущерб для работодателя.


S>Это из УК:

S>
S>"Халатность, то есть неисполнение или ненадлежащее исполнение должностным лицом своих обязанностей вследствие недобросовестного или небрежного отношения к службе либо обязанностей по должности, если это повлекло причинение крупного ущерба...
S>наказывается штрафом в размере до ста двадцати тысяч рублей или в размере заработной платы или иного дохода осужденного за период до одного года, либо обязательными работами на срок до трехсот шестидесяти часов, либо исправительными работами на срок до одного года, либо арестом на срок до трех месяцев."
S>


Крупным ущербом в настоящей статье признается ущерб, сумма которого превышает один миллион пятьсот тысяч рублей, а особо крупным — семь миллионов пятьсот тысяч рублей.

S>Либо в рамках ТК материальная ответственность на всю сумму причиненного ущерба, включая З.П., стоимость аренды и т.п. В случае с нематериальным активом доказать сложно.


а где такое в ТК? Есть цитата?
Re[3]: факапы на работе
От: alzt  
Дата: 05.04.17 06:26
Оценка:
Здравствуйте, sharpcoder, Вы писали:

S>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.


Это сильно понизит мотивацию и лояльность всех остальных сотрудников. Оно того стоит?
Re[2]: факапы на работе
От: alzt  
Дата: 05.04.17 06:31
Оценка:
Здравствуйте, Artem Korneev, Вы писали:

AK>Чтобы не было таких крупных факапов, нужно что-то менять в процессе. Если код ежедневно не коммитится в ветки разработчиков, то любые результаты работы более чем одного дня должны попадать или в код ревью или каким-то боком в систему контроля версий. В кривых системах вроде TFS есть "shelveset'ы", где можно просто сохраниться как есть. Git и прочие позволяют заводить ветки для каждого сотрудника.


Ещё зависит от задач. Иногда бывает полезным написать что-то за неделю, посмотреть на результат, поэкспериментировать. Потом выкинуть весь код и написать заново.
Re[2]: факапы на работе
От: El Camino Real США  
Дата: 05.04.17 06:32
Оценка:
Здравствуйте, Serg27, Вы писали:


S>Виноват системный администратор, который не наладил ежедневный бэкап на рабочих машинах и не проверил что он работает.

Именно. А как можно заставить человека отрабатывать в выходные или чего-то там лишить на неделю вообще слабо представляю. В окружающем социализме это будет означать конец конторе, а в России банальную потерю сотрудника по причине наличия рынка труда. Короче, впечатление, что менеджменту заняться нечем, кроме поиска виновных. Но культуру частых коммитов и пушей в индивидуальные бранчи надо бы привить в команде.
Re[6]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 06:49
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.


Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"? Нет, не слышали. И еще что-то о профнепригодности заявлем
www.blinnov.com
Re: факапы на работе
От: velkin Удмуртия http://blogs.rsdn.org/effective/
Дата: 05.04.17 07:07
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


Это классика: — "Кто виноват и что делать?". Неделя примерно равняется одной четвёртой месяца, то есть в деньгах зарплату программиста можно умножить на 0.25. Страшна не ошибка, а то что руководство не предпримет ничего её предотвращающую в будущем. Люди безответственны сами по себе, а ещё часто плохо организованы. Раз нет человека следящего за поступлением коммитов, значит никому недельное содержимое особо и не нужно.

Кто-то ищет людей способных делать всё самостоятельно. Кто-то организовывает процесс и благодаря этому даже плохо организованный человек способен работать продуктивно. Как любят говорить про японцев касаемо корпоративной культуры, а я сомневаюсь, что это так и тем не менее: — "Не бывает плохих солдат, бывают плохие генералы".

Если взглянуть на вакансии, то часто прослеживается желание иметь суперсолдата и дело даже не в деньгах, кто-то готов платить суперсолдату $300, кто-то $10'000. Как говорится: "Время расставит все по своим местам", что лучше порядок или хаос, большие зарплаты или нищета. Какое бы действие не было предпринято или наоборот потерять в глобальном плане могут все участники процесса.

Для этого и придумали управление рисками. Я вот ничего полезного кроме как для себя не делаю, при этом каждый мой коммит сразу уходит на личный сервер. Фатальный сбой или полное уничтожение компьютера приведёт к потере информацию не более чем за день, а то и меньше. Это лишь значит, что для меня ценна вся та муть, которую я пишу или рисую.
Re: факапы на работе
От: andrey.t  
Дата: 05.04.17 07:07
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


Здрасьте

HC>Как считаете это норм?


Факапы бывают — это нормально и вот прямо заставлять отрабатывать — это перебор. Хотя я бы сам наверное вышел без лишних уговоров. С другой стороны, если человек не учится на своих ошибках и повторит такое в обозримом будущем — гнать сразу ссаными тряпками.
Re[7]: факапы на работе
От: GarryIV  
Дата: 05.04.17 07:16
Оценка: :)
Здравствуйте, landerhigh, Вы писали:

GIV>>Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.


L>Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"? Нет, не слышали. И еще что-то о профнепригодности заявлем


Коллективный фаулер переделывал за вами сколько раз, утомился.
WBR, Igor Evgrafov
Re[7]: факапы на работе
От: John1979  
Дата: 05.04.17 07:25
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"? Нет, не слышали.

т.е. рефакторинг позволяет тебе держать несобираемый код днями ?
Re[2]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 07:28
Оценка:
Здравствуйте, Alexander G, Вы писали:

AG>Время занимает проектирование, отладка, выбор одного оптимального варианта из нескольких, изучение незнакомых АПИ, и т.д., а не сам набор кода.

AG>Ну то есть, утраченные изменения за неделю должны восстанавливаться не более, чем за день, их просто снова набрать.

Если речь про новый код, то это, кстати, правда. Второй вариант будет даже лучше первого. Но потерять первый может быть очень обидно
Re[8]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 07:28
Оценка:
Здравствуйте, John1979, Вы писали:

L>>Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"? Нет, не слышали.

J>т.е. рефакторинг позволяет тебе держать несобираемый код днями ?

Какой хороший детектор получился
www.blinnov.com
Re[6]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 07:31
Оценка: 11 (2) +4 :))) :)
Здравствуйте, GarryIV, Вы писали:

Pzz>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?


GIV>Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.


Существует класс задач, которые не решаются этими вашими методами из книжки. Такие задачи попадаются не каждый день, но иногда попадаются. Если вы держитесь за книжку, как за священное писание, от которого нельзя отступать, то наткнувшись случайно на такую задачу, вы ее не решите, и даже не поймете, почему. Этим мальчик отличается от мужа.
Re[2]: факапы на работе
От: ShaggyOwl Россия http://www.rsdn.org
Дата: 05.04.17 07:41
Оценка:
Здравствуйте, Serg27, Вы писали:

S>Виноват системный администратор, который не наладил ежедневный бэкап на рабочих машинах и не проверил что он работает.

Ежедневный (ночной) бекап рабочих машин — не очень хорошее решение.
Хорошо там, где мы есть! :)
Re[7]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 07:46
Оценка: +1
Здравствуйте, Pzz, Вы писали:

Pzz>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит. Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.

GIV>>Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.

Pzz>Существует класс задач, которые не решаются этими вашими методами из книжки. Такие задачи попадаются не каждый день, но иногда попадаются. Если вы держитесь за книжку, как за священное писание, от которого нельзя отступать, то наткнувшись случайно на такую задачу, вы ее не решите, и даже не поймете, почему. Этим мальчик отличается от мужа.
Можно пример?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: факапы на работе
От: John1979  
Дата: 05.04.17 08:01
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Существует класс задач, которые не решаются этими вашими методами из книжки.

причем тут книжка ?

Pzz>Если вы держитесь за книжку, как за священное писание

телепат ?
Re[8]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 08:37
Оценка:
Здравствуйте, ·, Вы писали:

Pzz>>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит.

И это магическим образом заставит код собираться, да?
Не надо собеседников за идиотов держать. Засунуть код в приватную ветку или на худой конец сложить на полку есть само собой разумеющееся.
www.blinnov.com
Re[4]: факапы на работе
От: Silver_S Ниоткуда  
Дата: 05.04.17 08:41
Оценка:
Здравствуйте, sharpcoder, Вы писали:


S>А по закону за это даже посадить можно, если доказать значительный ущерб для работодателя.


S>Это из УК:

S>[i]
S>"Халатность, то есть неисполнение или ненадлежащее исполнение должностным лицом своих обязанностей вследствие недобросовестного или небрежного отношения к службе либо обязанностей по должности, если это повлекло причинение крупного ущерба...
Случайно допущенные баги это тоже ущерб работодателю, и тоже ненадлежащее исполнение должностным лицом своих обязанностей ....
Я тоже однажды похерил результаты нескольких дней. В древние времена SourceSafe — точно не помню, второпях не внимательно прочитал вопрос в диалоге, из-за не правильного ответа безвозвратно откатилось назад(похерилось), ...
Это тоже попадает под статью?
Re[9]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 08:51
Оценка:
Здравствуйте, landerhigh, Вы писали:

Pzz>>>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

L>·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит.
L>И это магическим образом заставит код собираться, да?
Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать.
Понимаю ещё, что начал что-то делать, разломал всё, потом тебя отвлекли на митинг, а потом уже домой надо.

L>Не надо собеседников за идиотов держать. Засунуть код в приватную ветку или на худой конец сложить на полку есть само собой разумеющееся.

Ну судя по сабжу — само собой разумеющееся не для всех.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re: факапы на работе
От: Sammo Россия  
Дата: 05.04.17 09:23
Оценка:
HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать.
Личное имхо.
Есть сроки по задаче, он под ними подписался? Его вина? Тогда его проблемы.
У нас тут вчерась сервера упали у людей по полдня работы слетело (и сегодня частично). Админам втык, сроки на 2 дня сдвинули. Ибо зафиксировано и общая проблема.
А если ты накосячил, то сам себе злобный Буратино
Re: факапы на работе
От: De-Bill  
Дата: 05.04.17 09:24
Оценка:
HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Если тебя корёжит, то это точно не нормально. Если начальство конторы позволяет себе делать то, от чего корёжит большую часть коллектива, то как минимум они не очень умны.
Про факапы. К сожалению, они неизбежны. В том числе и по вине программистов. Но это не значит, что нужно заставлять править баги, например, в вне рабочее время.
Re[2]: факапы на работе
От: De-Bill  
Дата: 05.04.17 09:27
Оценка: +7
S>Есть сроки по задаче, он под ними подписался? Его вина? Тогда его проблемы.

Не стоит тратить свою жизнь работая в компаниях с таким подходом.
Re[10]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 09:44
Оценка:
Здравствуйте, ·, Вы писали:

L>>И это магическим образом заставит код собираться, да?

·>Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать.

Вот еще хороший вопрос для собеседования. На внимательность
Кто-то сказал "писать код"?

Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"?


L>>Не надо собеседников за идиотов держать. Засунуть код в приватную ветку или на худой конец сложить на полку есть само собой разумеющееся.

·>Ну судя по сабжу — само собой разумеющееся не для всех.

В некоторых конторах до сих пор используются недоразумения вроде ClearCase. Это не отменяет того факта, что оттуда нужно как можно быстрее делать ноги, но кроме "сам случайно потер исходники" бывает еще "создал такой merge hell, что приходится все мержить вручную"
www.blinnov.com
Re[11]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 09:56
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, ·, Вы писали:


L>>>И это магическим образом заставит код собираться, да?

L>·>Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать.
L>Вот еще хороший вопрос для собеседования. На внимательность
L>Кто-то сказал "писать код"?
L>

L>Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"?

Так... и? Такой рефакторинг проще проводить точечными изменениями, компилируя после каждого шага. И без частых коммитов сложно провернуть в принципе — чуть что и какой-нибудь не очень удачный массовый replace портит что-то так, что откатиться без VCS становится практически невозможным. А уж сколько радости будет когда через неделю таки закончишь и попробуешь обновиться до текущего мастера...

L>>>Не надо собеседников за идиотов держать. Засунуть код в приватную ветку или на худой конец сложить на полку есть само собой разумеющееся.

L>·>Ну судя по сабжу — само собой разумеющееся не для всех.
L>В некоторых конторах до сих пор используются недоразумения вроде ClearCase. Это не отменяет того факта, что оттуда нужно как можно быстрее делать ноги, но кроме "сам случайно потер исходники" бывает еще "создал такой merge hell, что приходится все мержить вручную"
Я в такой конторе плагин к гиту на баше написал для синхронизации git <-> cc и всё мержил в гите.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 10:00
Оценка: +1
Здравствуйте, ·, Вы писали:

L>>

L>>Рефакторинг ака "приведение окаменелых говен мамонта в сколь-нибудь удобоваримое состояние"?

·>Так... и? Такой рефакторинг проще проводить точечными изменениями, компилируя после каждого шага.

Везет же людям. Рефакторинг, который можно проводить точечными изменениями, среда со средствами для рефакторинга.
Ручками, все ручками. Разбивать зависимости, кромсать универсальные всемогуторы и выжигать статические переменные. Точечными изменениями тут уже не поможешь, тут ковровая бомбардировка нужна.

L>>В некоторых конторах до сих пор используются недоразумения вроде ClearCase. Это не отменяет того факта, что оттуда нужно как можно быстрее делать ноги, но кроме "сам случайно потер исходники" бывает еще "создал такой merge hell, что приходится все мержить вручную"

·>Я в такой конторе плагин к гиту на баше написал для синхронизации git <-> cc и всё мержил в гите.

В итоге все к подобным костылям и сводится
www.blinnov.com
Re[13]: факапы на работе
От: John1979  
Дата: 05.04.17 10:22
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Везет же людям. Рефакторинг, который можно проводить точечными изменениями, среда со средствами для рефакторинга.

L>Ручками, все ручками. Разбивать зависимости, кромсать универсальные всемогуторы и выжигать статические переменные. Точечными изменениями тут уже не поможешь, тут ковровая бомбардировка нужна.
когда я был молод и горяч, я рассуждал в том-же ключе. но однажды коллега убедил меня попробовать технику малых изменений с поддержанием кода не только в компилируемом, но и в рабочем состоянии.

с тех пор жить мне стало на порядок проще.
а уж на сколько порядков проще стало тем, кто ревьювит эти рефакторинги...
Re[14]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 10:33
Оценка:
Здравствуйте, John1979, Вы писали:

L>>Везет же людям. Рефакторинг, который можно проводить точечными изменениями, среда со средствами для рефакторинга.

L>>Ручками, все ручками. Разбивать зависимости, кромсать универсальные всемогуторы и выжигать статические переменные. Точечными изменениями тут уже не поможешь, тут ковровая бомбардировка нужна.
J>когда я был молод и горяч, я рассуждал в том-же ключе. но однажды коллега убедил меня попробовать технику малых изменений с поддержанием кода не только в компилируемом, но и в рабочем состоянии.

Это позавчера что ли?

Задачи и проблемы вообще-то бывают разные.
www.blinnov.com
Re[3]: факапы на работе
От: Serg27  
Дата: 05.04.17 10:54
Оценка:
Здравствуйте, ShaggyOwl, Вы писали:
SO>Ежедневный (ночной) бекап рабочих машин — не очень хорошее решение.

Переведи! (с)
Мнение интересное и, наверное, требует объяснения.
Re[15]: факапы на работе
От: John1979  
Дата: 05.04.17 11:01
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Это позавчера что ли?

это много лет назад.

L>Задачи и проблемы вообще-то бывают разные.

ну да, один ты уникальные вещи решаешь.
кстати, реальный пример задачи, которую невозможно решить 'не по книжке', ты так и не привел.
Re[7]: факапы на работе
От: John1979  
Дата: 05.04.17 11:02
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Не всякую работу можно разбить на кусочки по полчаса.

а на кусочки по 6 часов ?
Re[3]: факапы на работе
От: Hobbes Россия  
Дата: 05.04.17 11:03
Оценка:
Здравствуйте, alzt, Вы писали:

A>Ещё зависит от задач. Иногда бывает полезным написать что-то за неделю, посмотреть на результат, поэкспериментировать. Потом выкинуть весь код и написать заново.


Таки результат эксперимента, в том числе код, лучше всего сохранить где-то. Мало ли.
Re[5]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 11:58
Оценка:
Здравствуйте, Silver_S, Вы писали:

S_S> Я тоже однажды похерил результаты нескольких дней. В древние времена SourceSafe — точно не помню, второпях не внимательно прочитал вопрос в диалоге, из-за не правильного ответа безвозвратно откатилось назад(похерилось), ...

S_S> Это тоже попадает под статью?

Конечно попадает. Внедрение SourceSafe — это явное вредительство
Re[10]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 12:00
Оценка:
Здравствуйте, ·, Вы писали:

L>>И это магическим образом заставит код собираться, да?

·>Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать.
·>Понимаю ещё, что начал что-то делать, разломал всё, потом тебя отвлекли на митинг, а потом уже домой надо.

Твой кусок собирается. Проект в целом с твоим куском не собирается.
Re[4]: факапы на работе
От: ShaggyOwl Россия http://www.rsdn.org
Дата: 05.04.17 12:27
Оценка: +1
Здравствуйте, Serg27, Вы писали:

SO>>Ежедневный (ночной) бекап рабочих машин — не очень хорошее решение.


S>Переведи! (с)

S>Мнение интересное и, наверное, требует объяснения.

Сразу оговорюсь, что комментарий идёт в контексте темы (неиспользование репозитория).

Как по мне — работа с системой контроля версий для программиста, это что-то сродни гигиене. Надо чуть-чуть привыкнуть, а далее сплошной профит и отсутствие головняка. Бекап репозитория делается просто и занимает относительно немного времени. Причём, сложностей с этой задачей наверняка не будет.

Бекап _всех_ рабочих машин, это:
1. Выбор технических средств.
2. Настройка и отладка.
3. Контроль и исправление случающихся ошибок.
Т.е. этой задачей придётся целенаправленно заниматься и уделять ей время постоянно.

Далее, бекап всегда будет занимать _много_ времени и требовать _много_ места на внешнем хранилище. Как следствие решение будет не очень хорошо масштабироваться.
На контроле придётся постоянно держать предел для такого решения, который может быть достигнут довольно быстро в случае роста числа пользователей. Ну и стоимость решения надо считать внимательно. Отдельный вопрос — рост объёма информации на дисках пользователей. Ещё один отдельный вопрос — пропускная способность сети.
Самое главное. Профита от восстановления _каждого_ рабочего места разработчика будет совсем немного. С учётом использования системы контроля версий — так вообще никакой.

Как-то так.
Хорошо там, где мы есть! :)
Re[11]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 12:30
Оценка:
Здравствуйте, Pzz, Вы писали:

L>>>И это магическим образом заставит код собираться, да?

Pzz>·>Это мне до сих пор непонятно. Как можно три дня писать код и ни разу не смочь собрать.
Pzz>·>Понимаю ещё, что начал что-то делать, разломал всё, потом тебя отвлекли на митинг, а потом уже домой надо.
Pzz>Твой кусок собирается. Проект в целом с твоим куском не собирается.
Неужели это обнаруживается только на третий день?!
Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[8]: факапы на работе
От: Sharov Россия  
Дата: 05.04.17 12:34
Оценка:
Здравствуйте, ·, Вы писали:

·>Здравствуйте, Pzz, Вы писали:


Pzz>>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит.

А это зачем? Или это сленг такой?

·>Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.


Бекап разработчик должен оставлять/делать или администратор?
Кодом людям нужно помогать!
Re[16]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 12:39
Оценка:
Здравствуйте, John1979, Вы писали:

L>>Задачи и проблемы вообще-то бывают разные.

J>ну да, один ты уникальные вещи решаешь.

У меня тоже складывается такое мнение. Пока все гномиков сортируют, некоторым и работать приходится

J>кстати, реальный пример задачи, которую невозможно решить 'не по книжке', ты так и не привел.


Покажи, где я что-то говорил про книжки.
www.blinnov.com
Re[12]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 12:41
Оценка:
Здравствуйте, ·, Вы писали:

Pzz>>Твой кусок собирается. Проект в целом с твоим куском не собирается.

·>Неужели это обнаруживается только на третий день?!

Что значит "обнаруживается"? Это было известно с самого начала.

·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.


Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.
www.blinnov.com
Re[17]: факапы на работе
От: John1979  
Дата: 05.04.17 12:44
Оценка:
Здравствуйте, landerhigh, Вы писали:


J>>кстати, реальный пример задачи, которую невозможно решить 'не по книжке', ты так и не привел.

L>Покажи, где я что-то говорил про книжки.
пардон, это был не ты.
Re[13]: факапы на работе
От: John1979  
Дата: 05.04.17 12:48
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.

вносил, делается это за много шагов, но результатом каждой итерации у тебя работающий результат.

обычно эта зависимость не является единственной проблемой этого говнокода, поэтому сначала ты рефакторишь совсем не часть завязанную на глобальный объект, попутно подготавливая почву для отвязки от него.
Re[12]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 12:49
Оценка:
Здравствуйте, ·, Вы писали:

Pzz>>Твой кусок собирается. Проект в целом с твоим куском не собирается.

·>Неужели это обнаруживается только на третий день?!

Нет, немного другая ситуация.

Ты изолируешь проблему, и пытаешься ее починить для начала локально. Сознательно наплевав на то, что какие-то части проекта будут сломаны. Потом, если локальный ремонт достиг успеха, ты уже либо приведешь остальные части проекта в соответсвие, либо придумаешь, как сделать то же самое, сохранив совместимость (что может быть достаточно сложно). Но для начала тебе надо разобраться с тем, зачем ты вообще туда полез.

·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.


Я сам люблю все делать инкрементально. Но иногда "резать к чертовой матери" оказывается очень существенно делевле, чем инкрементально.
Re[14]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 12:50
Оценка: +1
Здравствуйте, John1979, Вы писали:

L>>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.

J>вносил, делается это за много шагов, но результатом каждой итерации у тебя работающий результат.

Не, не, речь была об одном инкрементальном изменени. "Много шагов" — это уже неувязочка.

J>обычно эта зависимость не является единственной проблемой этого говнокода, поэтому сначала ты рефакторишь совсем не часть завязанную на глобальный объект, попутно подготавливая почву для отвязки от него.


Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым.
www.blinnov.com
Re[13]: факапы на работе
От: John1979  
Дата: 05.04.17 12:55
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Но иногда

ты сам это сказал
исключительные ситуации бывают, но на то они и исключительные.
Re[15]: факапы на работе
От: John1979  
Дата: 05.04.17 12:58
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Не, не, речь была об одном инкрементальном изменени. "Много шагов" — это уже неувязочка.

бинарная логика детектед.
речь шла о поддержании проекта в :
— компилябельном
— рабочем

состояниях.

одно инкрементальное изменение гарантирует тебе оба пункта.
о том, что ты одним изменением фикснешь весь говнокод никто не говорил.

L>Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым.

собирается, работает и смысл есть.
при этом ревьюверу проще
при этом такой рефакторинг в огромных проектах может растянуться на месяцы, уделяться ему может 10-20% времени.
в результате у тебя и проект не стоит на месте, и при этом конюшни помаленьку чистятся.
Re[16]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 12:59
Оценка:
Здравствуйте, John1979, Вы писали:


L>>Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым.

J>собирается, работает и смысл есть.

Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде

www.blinnov.com
Re: факапы на работе
От: denisko http://sdeniskos.blogspot.com/
Дата: 05.04.17 13:07
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Не, не норм. Просто за эту неделю надо не заплатить и все.
<Подпись удалена модератором>
Re[17]: факапы на работе
От: John1979  
Дата: 05.04.17 13:19
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>Воот. И пока ты "подготавливаешь почву" проект либо просто не собирается, либо собриается, но не работает, либо просто нет смысла делать его собираемым.

J>>собирается, работает и смысл есть.

L>

L>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде

это требование ты сам придумал.
не вижу проблем сделать это в несколько итераций с поддержанием работоспособности проекта.
Re[18]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 13:20
Оценка:
Здравствуйте, John1979, Вы писали:

L>>

L>>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде

J>это требование ты сам придумал.

Это не я придумал. Это наследие говнокодов 25-летней давности.

J>не вижу проблем сделать это в несколько итераций с поддержанием работоспособности проекта.


Ты хотел сказать, что не знаешь, с каким проблемами это может быть сопряжено?
www.blinnov.com
Re[9]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 13:47
Оценка:
Здравствуйте, Sharov, Вы писали:

Pzz>>>>>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?

S>·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит.
S>А это зачем? Или это сленг такой?
git reset HEAD^
ну или --amend, ну или rebase и т.п.

S>·>Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.

S>Бекап разработчик должен оставлять/делать или администратор?
Разработчик, конечно. Ибо только он знает, что он такое сегодня наделал и что имеет хоть какую-то ценность. А тупо бэкапить весь диск без разбору — ЛохматыйСов уже хорошо объяснил выше чем это грозит.
А ещё приватную ветку легко можно будет передать другому/на другой компьютер/етс. С бэкапами почти ничего нельзя интересного сделать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[13]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 14:28
Оценка:
Здравствуйте, landerhigh, Вы писали:

Pzz>>>Твой кусок собирается. Проект в целом с твоим куском не собирается.

L>·>Неужели это обнаруживается только на третий день?!
L>Что значит "обнаруживается"? Это было известно с самого начала.
ну тем более. Сразу видно, что делаешь что-то не то.

L>·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.

L>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.
Да это же просто, типичный рефакторинг синглтона в Constructor Injection:
1. В каждом классе вначале выносишь ссылку на глобальный объект в методах как поле, инициализируя его в конструкторе. (каждый класс ≈ один коммит).
1а. Иногда ссылку на объект можно протащить через параметр метода. Это ещё часто простое решение при наличии циклических зависимостей, которые трудно распутать. (каждый метод ≈ один коммит)
2. Протаскиваешь его в конструктор как параметр. (каждый класс ≈ один коммит).
3. Переходишь к шагу 1 если ещё остались ссылки на глобальный объект не из Composition Root.
4. Заменяешь в Composition Root глобальное поле на локальную переменную, выкидываешь более неиспользуемое никем глобальное поле.
Т.е. начинать рефакторинг надо делать наизнанку. Начинать не с удаления самого глобального объекта, а с явного внедрения зависимостей от него во всех классах, его использущих.

Наверно коряво объяснил... Если приведёшь пример кода — могу по шагам расписать.

Так мы недавно исправляли что-то вроде System.currentMillis() на clock.millis() в ~1500 классах.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[2]: факапы на работе
От: playnext  
Дата: 05.04.17 14:36
Оценка:
Здравствуйте, denisko, Вы писали:

D>Здравствуйте, HoseCo, Вы писали:


HC>>Здрасте.


HC>>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

D>Не, не норм. Просто за эту неделю надо не заплатить и все.

Не, это тоже полумеры. Я в одной конторе работал там пытались штрафовать за то что подвигов не совершаешь.
Т. е. если работаешь в нормальном режиме а не перенапрягаешся или не выдаешь креативных решений улучшений оптимизаций и т д (причем это должно явно выразиться финасово для компании) — то это уже плохо. Так и гороили — нужны подвиги.
Штрафовали у вольняли за мелкие проступки. Не было тестирования, разработчик тестил сам, но время было ограничено. Мало того что разработчик не может эффективно протестить свой код так и еще время дается менеджером и впритык. Было также принято публично обсуждать косяки перед всем коллективом и позорить сотрудника. Приход на работу в 8 утра строго, уход в 17 (не строго). Никто правда не приходил к 8 (за редким исключением) обычно в 9, 10, но за это были выговоры. причем контора не банк.
Я до того как туда попал не знал что такое бывает.
Re[14]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 14:42
Оценка:
Здравствуйте, ·, Вы писали:

L>>Что значит "обнаруживается"? Это было известно с самого начала.

·>ну тем более. Сразу видно, что делаешь что-то не то.



L>>·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.

L>>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде. Только чтобы проект сразу и собирался и работал.
·>Да это же просто, типичный рефакторинг синглтона в Constructor Injection:
·>1. В каждом классе вначале выносишь ссылку на глобальный объект в методах как поле,

А ссылочка-то неявная. Через третью библиотечку протаскиваемая и этой третьей библиотечкой используемая. И избавиться от этой третьей библиотечки инкрементально не получится. Упс.

·>1.инициализируя его в конструкторе. (каждый класс ≈ один коммит).


Только проект либо не собирается, либо не работает. О чем и говорим.
www.blinnov.com
Re[4]: факапы на работе
От: Андрей Бабошин Германия http://andreybaboshin.livejournal.com/
Дата: 05.04.17 14:44
Оценка:
Здравствуйте, Kernan, Вы писали:

K>Здравствуйте, HoseCo, Вы писали:



HC>>похоже не комитил

K>Коммитил, но не пушил в origin.

Если это гит, то всё не так уж и плохо.
http://gitready.com/advanced/2009/01/17/restoring-lost-commits.html

коллега сегодня умудрился точно такой же трюк провернуть. Упс, и бранча — нет.
Re: факапы на работе
От: Pavel Dvorkin Россия  
Дата: 05.04.17 14:55
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


Насчет работы говорить не буду, но своим студентам на первом занятии я говорю примерно следующее.

Если за неделю до зачета Вы ко мне придете и скажете, что написали все как следует, но вот, увы, все пропало, я Вам искренне посочувствую, но предложу начать сначала.

А потом рассказываю про git.

Никто ни разу ко мне с таким заявлением не приходил.
With best regards
Pavel Dvorkin
Re[13]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 15:00
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>>>Твой кусок собирается. Проект в целом с твоим куском не собирается.

Pzz>·>Неужели это обнаруживается только на третий день?!
Pzz>Нет, немного другая ситуация.
Pzz>Ты изолируешь проблему, и пытаешься ее починить для начала локально. Сознательно наплевав на то, что какие-то части проекта будут сломаны. Потом, если локальный ремонт достиг успеха, ты уже либо приведешь остальные части проекта в соответсвие, либо придумаешь, как сделать то же самое, сохранив совместимость (что может быть достаточно сложно). Но для начала тебе надо разобраться с тем, зачем ты вообще туда полез.
Да, поиск бага/лучшего решения — может стать долгим и извилистым. Но когда достиг цели — лучше выбросить решение и всю "отладочную инфу", которую понапихал где ни попадя, и начать сначала небольшими рефакторингами, инкрементальными изменениями идти уже по проторенной дорожке.

Pzz>·>Хотя в общем понимаю, сам таким был. Но чем опытнее, тем случается такое реже и реже: легче находишь окольный путь инкрементального внесения изменений без всё-ломающих шагов.

Pzz>Я сам люблю все делать инкрементально. Но иногда "резать к чертовой матери" оказывается очень существенно делевле, чем инкрементально.
Но если это занимает сильно больше одного дня — это плохой знак.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[10]: факапы на работе
От: Sharov Россия  
Дата: 05.04.17 15:05
Оценка:
Здравствуйте, ·, Вы писали:

S>>·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит.

S>>А это зачем? Или это сленг такой?
·>git reset HEAD^
·>ну или --amend, ну или rebase и т.п.

Зачем это делать?


S>>·>Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.

S>>Бекап разработчик должен оставлять/делать или администратор?
·>Разработчик, конечно. Ибо только он знает, что он такое сегодня наделал и что имеет хоть какую-то ценность. А тупо бэкапить весь диск без разбору — ЛохматыйСов уже хорошо объяснил выше чем это грозит.
·>А ещё приватную ветку легко можно будет передать другому/на другой компьютер/етс. С бэкапами почти ничего нельзя интересного сделать.

Если я все закоммитил и запушил, что бэкапить тогда?
Кодом людям нужно помогать!
Re[15]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 15:09
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>·>Да это же просто, типичный рефакторинг синглтона в Constructor Injection:

L>·>1. В каждом классе вначале выносишь ссылку на глобальный объект в методах как поле,
L>А ссылочка-то неявная. Через третью библиотечку протаскиваемая и этой третьей библиотечкой используемая. И избавиться от этой третьей библиотечки инкрементально не получится. Упс.
В смысле библиотечку править нельзя что-ли? Ну тогда ты не сможешь избавиться от глобальной переменной. Хотя всё ещё можно хотя бы свой код очистить.

L>·>1.инициализируя его в конструкторе. (каждый класс ≈ один коммит).

L>Только проект либо не собирается, либо не работает. О чем и говорим.
Ну сделай чтобы собирался и работал, кто запрещает-то?!
Хинт: можно временно делать два конструктора|метода — один новый с явной зависимотью в параметре, второй старый "по умолчанию" из глобальной переменной. Потом правишь все места вызова старого на новый. Когда таких мест не осталось — грохаешь старый.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[19]: факапы на работе
От: John1979  
Дата: 05.04.17 15:17
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>

L>>>Ну внеси инкрементальное изменение, которое позволяет избавиться от зависимости от глобального объекта, отрастающего из легаси кода и используемого почти везде

J>>это требование ты сам придумал.

L>Это не я придумал. Это наследие говнокодов 25-летней давности.

говнокод 25 летней давности заставляет тебя выдвигать требование сделать рефакторинг в одну итерацию ?

J>>не вижу проблем сделать это в несколько итераций с поддержанием работоспособности проекта.

L>Ты хотел сказать, что не знаешь, с каким проблемами это может быть сопряжено?
я определенно знаю, что такой рефакторинг сопряжен с массой проблем. но я не вижу проблемы в том, чтоб сделать его итеративно.
более того, именно итеративный подход снижает вероятность ошибки и облегчает верификацию.
Re[16]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 15:18
Оценка:
Здравствуйте, ·, Вы писали:

L>>А ссылочка-то неявная. Через третью библиотечку протаскиваемая и этой третьей библиотечкой используемая. И избавиться от этой третьей библиотечки инкрементально не получится. Упс.

·>В смысле библиотечку править нельзя что-ли? Ну тогда ты не сможешь избавиться от глобальной переменной. Хотя всё ещё можно хотя бы свой код очистить.

Нельзя. Она сторонняя. Исходников нет, но есть ее новая версия или полная ее замена, на которую нужно перейти сразу.

L>>·>1.инициализируя его в конструкторе. (каждый класс ≈ один коммит).

L>>Только проект либо не собирается, либо не работает. О чем и говорим.
·>Ну сделай чтобы собирался и работал, кто запрещает-то?!

Давай, половина кода зависит от глобальной переменной, а другая — уже нет. При этом первая половина рассчитывает на то, что все пользуются этой глобальной переменной, иначе ничего не работает.
Время пошло

·>Хинт: можно временно делать два конструктора|метода — один новый с явной зависимотью в параметре, второй старый "по умолчанию" из глобальной переменной. Потом правишь все места вызова старого на новый. Когда таких мест не осталось — грохаешь старый.


Можно, только это решение какой-то другой проблемы.


P.S. Я не понял, тут вообще никто с легаси кодом не работал, что ли?
www.blinnov.com
Re[20]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 15:20
Оценка:
Здравствуйте, John1979, Вы писали:

L>>Это не я придумал. Это наследие говнокодов 25-летней давности.

J>говнокод 25 летней давности заставляет тебя выдвигать требование сделать рефакторинг в одну итерацию ?

Представь себе.
Нет, итераций ты можешь делать сколько угодно, но рабочей системы у тебя не получится до окончания рефакторинга.

J>>>не вижу проблем сделать это в несколько итераций с поддержанием работоспособности проекта.

L>>Ты хотел сказать, что не знаешь, с каким проблемами это может быть сопряжено?
J>я определенно знаю, что такой рефакторинг сопряжен с массой проблем. но я не вижу проблемы в том, чтоб сделать его итеративно.
J>более того, именно итеративный подход снижает вероятность ошибки и облегчает верификацию.

Читай в соседней ветке о глобальных переменных.
www.blinnov.com
Re[14]: факапы на работе
От: John1979  
Дата: 05.04.17 15:20
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Да это же просто, типичный рефакторинг синглтона в Constructor Injection:

ты описал один из самых простых рефакторингов.
на деле все бывает гораздо геморройнее, но, тем не менее, решаемо.
Re[17]: факапы на работе
От: John1979  
Дата: 05.04.17 15:26
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>P.S. Я не понял, тут вообще никто с легаси кодом не работал, что ли?

я рефакторил ядро фаервола написанного в C стиле в 9х годах, изначально работавшего в один поток, с кучей глобальных таблиц и переменных, к которому потом сбоку были прикручены потоки для проксирования, DPI и еще кучи мелких фиговин, с кучей мутексов и одним убер глобальным супермутексом.

после этого слушать про то, что что-то там нельзя рефакторить итеративно, потому что где-то там какая-то там глобальная фигня завелась... просто смешно.
Re[18]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 15:28
Оценка:
Здравствуйте, John1979, Вы писали:

L>>P.S. Я не понял, тут вообще никто с легаси кодом не работал, что ли?

J>я рефакторил ядро фаервола написанного в C стиле в 9х годах, изначально работавшего в один поток, с кучей глобальных таблиц и переменных, к которому потом сбоку были прикручены потоки для проксирования, DPI и еще кучи мелких фиговин, с кучей мутексов и одним убер глобальным супермутексом.

А слабо прочитать мое сообщение еще раз? А потом еще раз. До понимания, так сказать

J>после этого слушать про то, что что-то там нельзя рефакторить итеративно, потому что где-то там какая-то там глобальная фигня завелась... просто смешно.


Ага, абхахочешься.
www.blinnov.com
Re[17]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 15:45
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>А ссылочка-то неявная. Через третью библиотечку протаскиваемая и этой третьей библиотечкой используемая. И избавиться от этой третьей библиотечки инкрементально не получится. Упс.

L>·>В смысле библиотечку править нельзя что-ли? Ну тогда ты не сможешь избавиться от глобальной переменной. Хотя всё ещё можно хотя бы свой код очистить.
L>Нельзя. Она сторонняя. Исходников нет, но есть ее новая версия или полная ее замена, на которую нужно перейти сразу.
Надо смотреть по обстоятельствам. Но даже в самом тяжелом случае — всегда можно отделить библиотеку заменяемым фасадом.

L>Давай, половина кода зависит от глобальной переменной, а другая — уже нет. При этом первая половина рассчитывает на то, что все пользуются этой глобальной переменной, иначе ничего не работает.

L>Время пошло
Так говорю же. Код может использовать ту же глобальную переменную, но ссылаться на неё не напрямую из кода методов, а через параметры конструкторов/методов.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[18]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 15:50
Оценка:
Здравствуйте, ·, Вы писали:

L>>Нельзя. Она сторонняя. Исходников нет, но есть ее новая версия или полная ее замена, на которую нужно перейти сразу.

·>Надо смотреть по обстоятельствам. Но даже в самом тяжелом случае — всегда можно отделить библиотеку заменяемым фасадом.

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

L>>Давай, половина кода зависит от глобальной переменной, а другая — уже нет. При этом первая половина рассчитывает на то, что все пользуются этой глобальной переменной, иначе ничего не работает.

L>>Время пошло
·>Так говорю же. Код может использовать ту же глобальную переменную, но ссылаться на неё не напрямую из кода методов, а через параметры конструкторов/методов.

Твой код про глобальную переменную ничего не знает. Ее использует библиотека, написанная при царе горохе и никаких способов избавиться от этого глобального объекта не предоставляющая.
www.blinnov.com
Re[11]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 15:57
Оценка: 6 (1)
Здравствуйте, Sharov, Вы писали:

S>·>git reset HEAD^

S>·>ну или --amend, ну или rebase и т.п.
S>Зачем это делать?
Чтобы не публиковать сломанные коммиты.

S>>>Бекап разработчик должен оставлять/делать или администратор?

S>·>Разработчик, конечно. Ибо только он знает, что он такое сегодня наделал и что имеет хоть какую-то ценность. А тупо бэкапить весь диск без разбору — ЛохматыйСов уже хорошо объяснил выше чем это грозит.
S>·>А ещё приватную ветку легко можно будет передать другому/на другой компьютер/етс. С бэкапами почти ничего нельзя интересного сделать.
S>Если я все закоммитил и запушил, что бэкапить тогда?
Пуш — это и есть бэкап обычно. Я имел в виду, в том смысле что, не всякий пуш — бэкап, только если он делается на сервер физически расположенный в другом месте (и желательно в надёжной инфраструктуре).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[19]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 16:16
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>Нельзя. Она сторонняя. Исходников нет, но есть ее новая версия или полная ее замена, на которую нужно перейти сразу.

L>·>Надо смотреть по обстоятельствам. Но даже в самом тяжелом случае — всегда можно отделить библиотеку заменяемым фасадом.
L>Иногда так можно сделать. Но не всегда имеет смысл, например, низкоуровневая библиотека меняется на нечто, имеющее более человеческий интерфейс. И при этом код приводится в несобираемое состояние на довольно длительное время... особенно если происходит переход от pollig модели к асинхронным вызовам или еще чего похлеще.
Можно начать новый кусок кода рядом, потом одним махом заменить им старый.
В общем, я не пытаюсь убедить, что это просто, но вполне реально при наличии опыта и желания.

L>·>Так говорю же. Код может использовать ту же глобальную переменную, но ссылаться на неё не напрямую из кода методов, а через параметры конструкторов/методов.

L>Твой код про глобальную переменную ничего не знает. Ее использует библиотека, написанная при царе горохе и никаких способов избавиться от этого глобального объекта не предоставляющая.
И чем ломание кода поможет-то?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[20]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 16:19
Оценка:
Здравствуйте, ·, Вы писали:

·>Можно начать новый кусок кода рядом, потом одним махом заменить им старый.

·>В общем, я не пытаюсь убедить, что это просто, но вполне реально при наличии опыта и желания.

Заменить Макароны? Новым куском кода? Одним махом? Разве что махать осьминогом.

L>>·>Так говорю же. Код может использовать ту же глобальную переменную, но ссылаться на неё не напрямую из кода методов, а через параметры конструкторов/методов.

L>>Твой код про глобальную переменную ничего не знает. Ее использует библиотека, написанная при царе горохе и никаких способов избавиться от этого глобального объекта не предоставляющая.
·>И чем ломание кода поможет-то?

Выкорчевав легаси либу, можно получить возможность заменить ее на что-то удобоваримое. Но в процессе код придется, как тут выражались, сломать. И в таком состоянии он пробудет столько, сколько нужно.
www.blinnov.com
Re[3]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 16:21
Оценка:
Здравствуйте, playnext, Вы писали:

P>Т. е. если работаешь в нормальном режиме а не перенапрягаешся или не выдаешь креативных решений улучшений оптимизаций и т д (причем это должно явно выразиться финасово для компании) — то это уже плохо. Так и гороили — нужны подвиги.


Ну, т.е. выигрышная стратегия — тихонько создавать проблемы, а потом героически их решать.

P>Я до того как туда попал не знал что такое бывает.


Что заставляет людей оставаться в таких конторах дольше, чем требует ТК?
Re[2]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 16:22
Оценка:
Здравствуйте, denisko, Вы писали:

D>Не, не норм. Просто за эту неделю надо не заплатить и все.


Это не законно, между прочим.
Re[16]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 16:27
Оценка:
Здравствуйте, John1979, Вы писали:

J>при этом такой рефакторинг в огромных проектах может растянуться на месяцы, уделяться ему может 10-20% времени.

J>в результате у тебя и проект не стоит на месте, и при этом конюшни помаленьку чистятся.

А теперь представь себе, что из-за ошибки (причем неочевидной ошибки, которую малой кровью не исправишь) в глобальном объекте невозможно сделать фичу, которую надо на след. неделе показать важному заказчику, который подпишет контракт на миллион, но сначала увидит эту фичу работающей. А тут ты такой, с предложением инкрементально рефакторить два месяца, уделяя этому процессу 10-20% времени.
Re[21]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 17:08
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>·>Можно начать новый кусок кода рядом, потом одним махом заменить им старый.

L>·>В общем, я не пытаюсь убедить, что это просто, но вполне реально при наличии опыта и желания.
L>Заменить Макароны? Новым куском кода? Одним махом? Разве что махать осьминогом.
А что такого? Написать новую имплементацию, внедрить, выкинуть старую. Но тут уж какие-то серьёзные изменения, не работа трёх дней.

L>>>·>Так говорю же. Код может использовать ту же глобальную переменную, но ссылаться на неё не напрямую из кода методов, а через параметры конструкторов/методов.

L>>>Твой код про глобальную переменную ничего не знает. Ее использует библиотека, написанная при царе горохе и никаких способов избавиться от этого глобального объекта не предоставляющая.
L>·>И чем ломание кода поможет-то?
L>Выкорчевав легаси либу, можно получить возможность заменить ее на что-то удобоваримое. Но в процессе код придется, как тут выражались, сломать. И в таком состоянии он пробудет столько, сколько нужно.
Столько сколько нужно без коммитов и бекапов?! Это полный сабж.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[19]: факапы на работе
От: John1979  
Дата: 05.04.17 18:32
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>P.S. Я не понял, тут вообще никто с легаси кодом не работал, что ли?

J>>я рефакторил ядро фаервола написанного в C стиле в 9х годах, изначально работавшего в один поток, с кучей глобальных таблиц и переменных, к которому потом сбоку были прикручены потоки для проксирования, DPI и еще кучи мелких фиговин, с кучей мутексов и одним убер глобальным супермутексом.

L>А слабо прочитать мое сообщение еще раз? А потом еще раз. До понимания, так сказать

прочитал, что не так ? и зачем ты выделил слово 'ядро' ?
Re[20]: факапы на работе
От: John1979  
Дата: 05.04.17 18:34
Оценка:
Здравствуйте, ·, Вы писали:

·>Можно начать новый кусок кода рядом, потом одним махом заменить им старый.

·>В общем, я не пытаюсь убедить, что это просто, но вполне реально при наличии опыта и желания.
но ведь проще сказать 'это невозможно', сделать умную мину и уйти изображать бурную деятельность, выдав потом на ревью кусок с 20 тысячами изменений.
Re[17]: факапы на работе
От: John1979  
Дата: 05.04.17 18:36
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>А теперь представь себе, что из-за ошибки (причем неочевидной ошибки, которую малой кровью не исправишь) в глобальном объекте невозможно сделать фичу, которую надо на след. неделе показать важному заказчику, который подпишет контракт на миллион, но сначала увидит эту фичу работающей. А тут ты такой, с предложением инкрементально рефакторить два месяца, уделяя этому процессу 10-20% времени.

в третий, если не ошибаюсь, раз повторяю — исключительные ситуации на то и исключительные. нет смысла их обсуждать. а если у тебя вся работа — исключительные ситуации, то тут одно из двух, но скорее первое.
Re[7]: факапы на работе
От: GarryIV  
Дата: 05.04.17 20:35
Оценка: :)
Здравствуйте, Pzz, Вы писали:

Pzz>Существует класс задач, которые не решаются этими вашими методами из книжки. Такие задачи попадаются не каждый день, но иногда попадаются. Если вы держитесь за книжку, как за священное писание, от которого нельзя отступать, то наткнувшись случайно на такую задачу, вы ее не решите, и даже не поймете, почему. Этим мальчик отличается от мужа.


Просто опыта маловато, научитесь со временем при должном старании.
WBR, Igor Evgrafov
Re[22]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 20:48
Оценка:
Здравствуйте, ·, Вы писали:

L>>Заменить Макароны? Новым куском кода? Одним махом? Разве что махать осьминогом.

·>А что такого? Написать новую имплементацию, внедрить, выкинуть старую. Но тут уж какие-то серьёзные изменения, не работа трёх дней.

А вот тут кое-кто выше по ветке слова вроде "профнепригоден" использовал.

L>>·>И чем ломание кода поможет-то?

L>>Выкорчевав легаси либу, можно получить возможность заменить ее на что-то удобоваримое. Но в процессе код придется, как тут выражались, сломать. И в таком состоянии он пробудет столько, сколько нужно.
·>Столько сколько нужно без коммитов и бекапов?! Это полный сабж.

А причем тут коммиты и бекапы? Тут народ бил себя пятков в грудь, что они все, что угодно, за день рефакторят.

P.S. Это если на секунду забыть, что никакой "новой имплементации" нет. Меняется в перую очередь API либы, а вместе с ней и клиентский код.
www.blinnov.com
Re[8]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 05.04.17 20:52
Оценка: +1
Здравствуйте, GarryIV, Вы писали:

Pzz>>Существует класс задач, которые не решаются этими вашими методами из книжки. Такие задачи попадаются не каждый день, но иногда попадаются. Если вы держитесь за книжку, как за священное писание, от которого нельзя отступать, то наткнувшись случайно на такую задачу, вы ее не решите, и даже не поймете, почему. Этим мальчик отличается от мужа.


GIV>Просто опыта маловато, научитесь со временем при должном старании.


Re[6]: факапы на работе
От: GarryIV  
Дата: 05.04.17 21:04
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.


Вот не ожидал, что так массово не собирается по три дня. Может у вас какое-то другое пониммание термина "не собирается"?

UPD: Посмотрел на чам пишут несогласные — подавляющее большиство C++, у Дяди Федора только C# не собирается по три дня.
WBR, Igor Evgrafov
Отредактировано 05.04.2017 21:12 GarryIV . Предыдущая версия .
Re[23]: факапы на работе
От: · Великобритания  
Дата: 05.04.17 21:04
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>Заменить Макароны? Новым куском кода? Одним махом? Разве что махать осьминогом.

L>·>А что такого? Написать новую имплементацию, внедрить, выкинуть старую. Но тут уж какие-то серьёзные изменения, не работа трёх дней.
L>А вот тут кое-кто выше по ветке слова вроде "профнепригоден" использовал.
Я уже перестал следить и понимать какую конкретно задачу ты пытаешься решить, тебя всё что-то туда-сюда колбасит: то глобальная переменная, то либа, то вторая либа, то макароны, то переписывание на асинхронность. А ты, видимо, ждёшь что я обломаюсь универсальный рецепт решения всех проблем выдать.

L>>>·>И чем ломание кода поможет-то?

L>>>Выкорчевав легаси либу, можно получить возможность заменить ее на что-то удобоваримое. Но в процессе код придется, как тут выражались, сломать. И в таком состоянии он пробудет столько, сколько нужно.
L>·>Столько сколько нужно без коммитов и бекапов?! Это полный сабж.
L>А причем тут коммиты и бекапы?
У топикстатрера было.

L>Тут народ бил себя пятков в грудь, что они все, что угодно, за день рефакторят.

Не знаю кто. Цитаты плиз. Наоборот было "растянуться на месяцы, уделяться ему [рефакторингу] может 10-20% времени".

L>P.S. Это если на секунду забыть, что никакой "новой имплементации" нет. Меняется в перую очередь API либы, а вместе с ней и клиентский код.

Новую имплементацию надо написать поверх новой либы, не ломая старую имплеметацию.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: факапы на работе
От: landerhigh Пират  
Дата: 05.04.17 21:46
Оценка:
Здравствуйте, ·, Вы писали:

L>>А вот тут кое-кто выше по ветке слова вроде "профнепригоден" использовал.

·>Я уже перестал следить и понимать какую конкретно задачу ты пытаешься решить, тебя всё что-то туда-сюда колбасит: то глобальная переменная, то либа, то вторая либа, то макароны, то переписывание на асинхронность.

Это все та же задача. Есть код, который использовал древнюю, как говно мамонта, либу со своим чудовищным апи. Переписывание откладывали до упора, но все, приехали. Надо решать проблему, но это ни разу не на пару дней задача.

·>А ты, видимо, ждёшь что я обломаюсь универсальный рецепт решения всех проблем выдать.


А ты как думал?

L>>Тут народ бил себя пятков в грудь, что они все, что угодно, за день рефакторят.

·>Не знаю кто. Цитаты плиз. Наоборот было "растянуться на месяцы, уделяться ему [рефакторингу] может 10-20% времени".

Это деццкий рефакторинг. Подчищание багов, убирание зависимостей и наведение красивостей.

L>>P.S. Это если на секунду забыть, что никакой "новой имплементации" нет. Меняется в перую очередь API либы, а вместе с ней и клиентский код.

·>Новую имплементацию надо написать поверх новой либы, не ломая старую имплеметацию.

Иногда это абсолютно бессмысленно.
www.blinnov.com
Re[25]: факапы на работе
От: · Великобритания  
Дата: 06.04.17 07:56
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>·>Я уже перестал следить и понимать какую конкретно задачу ты пытаешься решить, тебя всё что-то туда-сюда колбасит: то глобальная переменная, то либа, то вторая либа, то макароны, то переписывание на асинхронность.

L>Это все та же задача. Есть код, который использовал древнюю, как говно мамонта, либу со своим чудовищным апи. Переписывание откладывали до упора, но все, приехали. Надо решать проблему, но это ни разу не на пару дней задача.
Так сколько дней? Неделя, как в начале топика и с тем же результатом?
Зачем ломать существующий код? Почему нельзя написать новый рядом?

L>·>А ты, видимо, ждёшь что я обломаюсь универсальный рецепт решения всех проблем выдать.

L>А ты как думал?
Что тебе интереснее научиться чему-то новому, а не доказать что ты всегда прав.

L>>>Тут народ бил себя пятков в грудь, что они все, что угодно, за день рефакторят.

L>·>Не знаю кто. Цитаты плиз. Наоборот было "растянуться на месяцы, уделяться ему [рефакторингу] может 10-20% времени".
L>Это деццкий рефакторинг. Подчищание багов, убирание зависимостей и наведение красивостей.
Чем больше опыта, тем больше рефакторингов — деццкие.

L>>>P.S. Это если на секунду забыть, что никакой "новой имплементации" нет. Меняется в перую очередь API либы, а вместе с ней и клиентский код.

L>·>Новую имплементацию надо написать поверх новой либы, не ломая старую имплеметацию.
L>Иногда это абсолютно бессмысленно.
При наличии должного опыта это если и занимает больше времени, то незначительно, но даёт более стабильный результат.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[4]: факапы на работе
От: playnext  
Дата: 06.04.17 08:39
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, playnext, Вы писали:


P>>Т. е. если работаешь в нормальном режиме а не перенапрягаешся или не выдаешь креативных решений улучшений оптимизаций и т д (причем это должно явно выразиться финасово для компании) — то это уже плохо. Так и гороили — нужны подвиги.


Pzz>Ну, т.е. выигрышная стратегия — тихонько создавать проблемы, а потом героически их решать.

Проблемы тоже создавать надо уметь.

P>>Я до того как туда попал не знал что такое бывает.


Pzz>Что заставляет людей оставаться в таких конторах дольше, чем требует ТК?

Не знаю честно о всех. Я там проработал около года. Была ипотека и кризис в 2009 году. Сложно было работу найти с нормальной зарплатой. Я там был на позиции Team Lead, платили приемлемо.
Re[26]: факапы на работе
От: landerhigh Пират  
Дата: 06.04.17 09:55
Оценка:
Здравствуйте, ·, Вы писали:

L>>Это все та же задача. Есть код, который использовал древнюю, как говно мамонта, либу со своим чудовищным апи. Переписывание откладывали до упора, но все, приехали. Надо решать проблему, но это ни разу не на пару дней задача.

·>Так сколько дней? Неделя, как в начале топика и с тем же результатом?

Неважно сколько. Важно, что это ни разу не пара дней, и в эти ни разу не пару дней в твоей конкретной ветке проект если и собирается, то не работает.

·>Зачем ломать существующий код? Почему нельзя написать новый рядом?


А почему бы тогда вообще все не переписать с нуля?
www.blinnov.com
Re: факапы на работе
От: John1979  
Дата: 06.04.17 10:07
Оценка:
Здравствуйте, HoseCo, Вы писали:

факап, очевидно, посерьезрнее потери недели работы.
https://habrahabr.ru/company/yamoney/blog/325762/

про наказания и прочее там тоже написано
Re[27]: факапы на работе
От: · Великобритания  
Дата: 06.04.17 10:33
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>·>Так сколько дней? Неделя, как в начале топика и с тем же результатом?

L>Неважно сколько. Важно, что это ни разу не пара дней, и в эти ни разу не пару дней в твоей конкретной ветке проект если и собирается, то не работает.
Это уже лучше. Как минимум — собирается и позволяет запускать тесты. И нужно понимать, что ветка живущая дольше нескольких дней — плохая идея для активно развивающегося проекта.

L>·>Зачем ломать существующий код? Почему нельзя написать новый рядом?

L>А почему бы тогда вообще все не переписать с нуля?
Тоже как вариант, если масштаб изменений достаточно большой.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[7]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 11:02
Оценка: +1
Здравствуйте, GarryIV, Вы писали:

GIV>Вот не ожидал, что так массово не собирается по три дня. Может у вас какое-то другое пониммание термина "не собирается"?


Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.
Re[8]: факапы на работе
От: landerhigh Пират  
Дата: 06.04.17 11:17
Оценка: +2
Здравствуйте, kaa.python, Вы писали:

KP>Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.


Более простой и имхо часто встречающийся пример — миграция огромного проекта с Visual Studio 6.0 на более современную версию, когда уже совсем приперло. Думаю, через такое проходили все плюсисты.
www.blinnov.com
Re[9]: факапы на работе
От: John1979  
Дата: 06.04.17 11:27
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Здравствуйте, kaa.python, Вы писали:


KP>>Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.


L>Более простой и имхо часто встречающийся пример — миграция огромного проекта с Visual Studio 6.0 на более современную версию, когда уже совсем приперло. Думаю, через такое проходили все плюсисты.

как часто в своем проекте ты мигрируешь гигабайтный проект с вижуал студио 6 на С++11 ?
зачем вы цепляетесь за какие-то исключительные случаи ?
Re[10]: факапы на работе
От: landerhigh Пират  
Дата: 06.04.17 11:37
Оценка:
Здравствуйте, John1979, Вы писали:


L>>Более простой и имхо часто встречающийся пример — миграция огромного проекта с Visual Studio 6.0 на более современную версию, когда уже совсем приперло. Думаю, через такое проходили все плюсисты.

J>как часто в своем проекте ты мигрируешь гигабайтный проект с вижуал студио 6 на С++11 ?

Достаточно и одного раза.

J>зачем вы цепляетесь за какие-то исключительные случаи ?


Вообще-то инженерам платят именно за нахождение решений в исключительных случаях. Рутинной работой занимаются кодеры и техподдержка.
www.blinnov.com
Re[10]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 11:38
Оценка:
Здравствуйте, John1979, Вы писали:

J>как часто в своем проекте ты мигрируешь гигабайтный проект с вижуал студио 6 на С++11 ?

J>зачем вы цепляетесь за какие-то исключительные случаи ?

Да бывают не исключительные, к примеру сегодня заменил Json подобный протокол с кучей констант на Protobuf в одной из частей проекта. Работал с прошлой пятницы, комит чего-то минимально осмысленного сделал только сегодня под вечер.
Re[11]: факапы на работе
От: John1979  
Дата: 06.04.17 11:42
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Достаточно и одного раза.

достаточно для чего ?

L>Вообще-то инженерам платят именно за нахождение решений в исключительных случаях. Рутинной работой занимаются кодеры и техподдержка.

пальцы растопырить забыл.
Re[11]: факапы на работе
От: John1979  
Дата: 06.04.17 11:44
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Да бывают не исключительные, к примеру сегодня заменил Json подобный протокол с кучей констант на Protobuf в одной из частей проекта. Работал с прошлой пятницы, комит чего-то минимально осмысленного сделал только сегодня под вечер.

и ты возьмешься утверждаешь, что это нельзя было сделать итеративно ? (оставим за скобками оверхид)
Re[2]: факапы на работе
От: Gradiens  
Дата: 06.04.17 12:18
Оценка:
Здравствуйте, Sammo, Вы писали:

S>Есть сроки по задаче, он под ними подписался? Его вина? Тогда его проблемы.

А это с какого перепугу?
Если он — простой наемный работник, тогда это проблемы работодателя.
Вот был бы субподрядчиком — другой вопрос.
Re[2]: факапы на работе
От: Gradiens  
Дата: 06.04.17 12:32
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Насчет работы говорить не буду, но своим студентам на первом занятии я говорю примерно следующее.

PD>Если за неделю до зачета Вы ко мне придете и скажете, что написали все как следует, но вот, увы, все пропало, я Вам искренне посочувствую, но предложу начать сначала.
Это другое.
Если фрилансер мне будет рассказывать, что у него накрылся диск — это его проблемы. Я ему посочувствую, но денег не заплачу.
Если при ремонте квартиры строитель будет рассказывать что он испортил материал — это его проблема. Я ему даже сочувствовать не буду и штрафану на стоимость материала.
Они несут все риски, но при этом получают всю прибыль.

Но штрафовать штатного сотрудника (временем или деньгами), чтобы компенсировать конторе убытки — неверно. Контора же не делится процентом прибыли? Ну так пусть и убытками не делится.
Re[12]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 12:49
Оценка:
Здравствуйте, John1979, Вы писали:

J>и ты возьмешься утверждаешь, что это нельзя было сделать итеративно ? (оставим за скобками оверхид)


Я и делаю итеративно. Минимальная осмысленного итерация заняла 4 дня
Re[8]: факапы на работе
От: · Великобритания  
Дата: 06.04.17 13:20
Оценка:
Здравствуйте, kaa.python, Вы писали:

GIV>>Вот не ожидал, что так массово не собирается по три дня. Может у вас какое-то другое пониммание термина "не собирается"?

KP>Пример из практики: миграция огромного проекта (под гигабайт кода и сопутствующего барахла) с C++03 на C++11. Работа заняла под месяц в течении которого кодовая база то не компилировалась, то не линковалось, то просто падало всё.
Это у вас какой-то полудохлый проект с одним разработчиком, похоже. Видимо, было допустимо на целый месяц остановить разработку текущей версии и потратить столько времени на миграцию.
Серьёзные проекты в таком случае перетаскивают по кусочкам: потихоньку модицифируют код, вставляя какие-нибудь #ifdef/etc чтобы он начал собираться и работать под обе версии плюсов, потом вычищают старую, если надо. Да, такое может занять два месяца, но риски гораздо ниже.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[13]: факапы на работе
От: John1979  
Дата: 06.04.17 13:26
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Я и делаю итеративно. Минимальная осмысленного итерация заняла 4 дня

мне, конечно, со стороны не видно, но неужели нельзя было отгородиться интерфейсами и потом просто заменить прокладку с json на протобуфер ?
Re[14]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 13:29
Оценка:
Здравствуйте, John1979, Вы писали:

J>мне, конечно, со стороны не видно, но неужели нельзя было отгородиться интерфейсами и потом просто заменить прокладку с json на протобуфер ?


Можно было, но заработало бы к концу следующей недели, а так работает уже сегодня.
Re[9]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 13:35
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Это у вас какой-то полудохлый проект с одним разработчиком, похоже. Видимо, было допустимо на целый месяц остановить разработку текущей версии и потратить столько времени на миграцию.


Этот "полудохлый" проект был изрядной частью кодовой базы Антивируса Касперского. К счастью не весь, а только macOS и кроссплатформенная части.

·>Серьёзные проекты в таком случае перетаскивают по кусочкам: потихоньку модицифируют код, вставляя какие-нибудь #ifdef/etc чтобы он начал собираться и работать под обе версии плюсов, потом вычищают старую, если надо. Да, такое может занять два месяца, но риски гораздо ниже.


При таком подходе смешивались два рантайма: libcpp и libc++, что недопустимо.

Так что я бы не стал дальше на твоем месте тут пальцы гнуть и про серьезные проекты говорить.
Отредактировано 06.04.2017 13:37 kaa.python . Предыдущая версия .
Re[15]: факапы на работе
От: John1979  
Дата: 06.04.17 13:44
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Можно было, но заработало бы к концу следующей недели, а так работает уже сегодня.

об чем и спич, т.е. принципиально это возможно.

в некоторых ситуациях правильнее сделать все как можно более мелкими итерациями, в некоторых можно на это забить и все разломать на неделю/месяц.

я стараюсь придерживаться первого пути, но второе тоже случается. однако я считаю второй путь годным для исключительных ситуаций.
Re[16]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 13:51
Оценка:
Здравствуйте, John1979, Вы писали:

J>в некоторых ситуациях правильнее сделать все как можно более мелкими итерациями, в некоторых можно на это забить и все разломать на неделю/месяц.


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

Я тоже за итеративные изменения, просто нет ничего страшного в том, что длинна итерации составляет одну неделю. Зачем привязывается к одному или двум дням?
Re[3]: факапы на работе
От: Pavel Dvorkin Россия  
Дата: 06.04.17 13:55
Оценка:
Здравствуйте, Gradiens, Вы писали:

G>Здравствуйте, Pavel Dvorkin, Вы писали:


G>Если фрилансер мне будет рассказывать, что у него накрылся диск — это его проблемы. Я ему посочувствую, но денег не заплачу.

G>Но штрафовать штатного сотрудника (временем или деньгами), чтобы компенсировать конторе убытки — неверно. Контора же не делится процентом прибыли? Ну так пусть и убытками не делится.

Мне не совсем ясно, в чем разница. А если фрилансер (да хоть кто угодно) принят на срочный договор ? В штате числится, но временно. Контракт на 4 месяца, 3 из них уже прошло, зарплату ему за них платили. А если он принят на договор, но на конкретную работу, без срока ? Где граница ?
With best regards
Pavel Dvorkin
Отредактировано 06.04.2017 13:58 Pavel Dvorkin . Предыдущая версия . Еще …
Отредактировано 06.04.2017 13:57 Pavel Dvorkin . Предыдущая версия .
Re[10]: факапы на работе
От: · Великобритания  
Дата: 06.04.17 14:02
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>·>Серьёзные проекты в таком случае перетаскивают по кусочкам: потихоньку модицифируют код, вставляя какие-нибудь #ifdef/etc чтобы он начал собираться и работать под обе версии плюсов, потом вычищают старую, если надо. Да, такое может занять два месяца, но риски гораздо ниже.

KP>При таком подходе смешивались два рантайма: libcpp и libc++, что недопустимо.
Что значит "смешивались"? Просто один и тот же исходник проекта собирается разными компиляторами. Для С/С++ мира это заурядное явление, ничего ни у кого не смешивается.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[17]: факапы на работе
От: John1979  
Дата: 06.04.17 14:04
Оценка:
Здравствуйте, kaa.python, Вы писали:

KP>Так то что разломано — оно же никого кроме меня не затронуло, живет себе в отдельной ветке и кушать не просит. Зачем мне увеличивать свою работу в два раза?


если увеличит в 2 раза, то это, конечно, повод задуматься. в такой ситуации, возможно, проще забить и сломать.

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

KP>Зачем привязывается к одному или двум дням?

упрощение процесса. я не молюсь на какие-то догмы, но если за счет увеличения сроков на 30% удастся в разы уменьшить его сложность — почему нет ?
Re[5]: факапы на работе
От: sharpcoder Россия  
Дата: 06.04.17 14:44
Оценка:
Здравствуйте, Silver_S, Вы писали:

S_S> Случайно допущенные баги это тоже ущерб работодателю, и тоже ненадлежащее исполнение должностным лицом своих обязанностей ....

S_S> Я тоже однажды похерил результаты нескольких дней. В древние времена SourceSafe — точно не помню, второпях не внимательно прочитал вопрос в диалоге, из-за не правильного ответа безвозвратно откатилось назад(похерилось), ...
S_S> Это тоже попадает под статью?

И да и нет.
Да, т.е. это ущерб, вполне реальный.
А нет — потому что ущерб не большой, и работодатель не стал (и прав в этом) из-за него заморачиваться.
Отредактировано 07.04.2017 1:15 kaa.python . Предыдущая версия .
Re[4]: факапы на работе
От: sharpcoder Россия  
Дата: 06.04.17 14:48
Оценка:
Здравствуйте, John1979, Вы писали:

J>Здравствуйте, sharpcoder, Вы писали:


S>>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.

S>>http://base.garant.ru/12125268/39/#friends
J>и много людей ты уже поштрафовал ?

Штрафы не доводилось применять, честно. В ИТ так не принято. Приходится работать в соответствии с общими стандартами рынка
Re[4]: факапы на работе
От: sharpcoder Россия  
Дата: 06.04.17 14:53
Оценка:
Здравствуйте, bazis1, Вы писали:

B>Здравствуйте, sharpcoder, Вы писали:


S>>Что за фантазии?

B>Это не фантазии, это принятие реальности. Думаешь мне эта ситуация нравится?
S>>В бизнесе риски всегда на получателе денег, а не на плательщике.
B>В общем случае — да. Но трудовые отношения — это отдельная сильно зарегулированная тема.

Так и не надо писать "в бизнесе". Пиши в "трудовых отношениях".

S>>Конечно, наемные работники поивыкли к подходу "я ни за что не отвечаю", но этот подход ошибочный.

S>>Закон предусматривает очень много разной ответственности за факапы, от компенсации ущерба в размере месячной зарплаты (а для этого даже суд не нужен), до компенсации в полном объеме и даже уголовка — если ущерб крупный.
B>Ты забываешь, что рынок труда — это такой же рынок, как и остальные. Если подобные вещи пытаться по всей строгости применять, то к тебе просто работать никто не пойдет. Потому что за углом за ту же зарплату котики, печеньки и nine to five.

С чего ты взял, что я это забываю?
Забывал бы — сам применял бы. Но я работаю на том же рынке и ценность большинства спецов выше, чем их недельная зарплата.
Поэтому зажать зарплату за неделю и потерять специалиста для меня очень не выгодно было бы.
А вот если бы это были, условно, разнорабочие — то с ними вполне реальны такие штрафы. И их успешно применяют.

B>Плюс, менеджмент же. Если человек — обычный винтик, то закрыв глаза на факап (и правильно это обыграв) ты получишь лояльного сотрудника, которому можно в долгосрочной перспективе меньше платить. Если он хороший спец — то все равно второго такого искать дороже. В общем, от прямой конфронтации обычно проигрывают все, за исключением эго конфронтирующего.


Ты учишь меня работать?
Я то ценю своих спецов, очень даже!

S>>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.

S>>http://base.garant.ru/12125268/39/#friends
B>По твоей же ссылке:
B>

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

B>Под прямым действительным ущербом понимается реальное уменьшение наличного имущества работодателя или ухудшение состояния указанного имущества (в том числе имущества третьих лиц, находящегося у работодателя, если работодатель несет ответственность за сохранность этого имущества), а также необходимость для работодателя произвести затраты либо излишние выплаты на приобретение, восстановление имущества либо на возмещение ущерба, причиненного работником третьим лицам.

B>С недописанным софтом замучаешься доказывать. Ну заявит работник, что имущество (софт) хранилось на оборудовании работодателя и было утеряно вследствие дефекта оборудования (баг FS). И все, приплыли. Если нет четких письменных должностных инструкций, где прописано, что куда и как часто бэкапить, то с работника спроса нет.

Доказать можно. Привлечь свидетелей и т.п. Легко.
Просто если ущерб не значительный, то себе дороже людей штрафовать — больше потеряешь из-за текучки.

B>P.S. Мне все вышеописанное не нравится, но практика показывает, что подход "я работник, я решаю производственные задачи в обмен на кэш, и оставляю эмоции, интриги и чувства за порогом" в реальном мире не работает, как бы мне не хотелось обратного.


В каких-то отраслях работает в каких-то нет. ИТ в этом плане сложный бизнес, очень завязан на людей.
Re[4]: факапы на работе
От: sharpcoder Россия  
Дата: 06.04.17 14:55
Оценка:
Здравствуйте, alzt, Вы писали:

A>Здравствуйте, sharpcoder, Вы писали:


S>>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.


A>Это сильно понизит мотивацию и лояльность всех остальных сотрудников. Оно того стоит?


Нет, но вопрос то изначально был не об этом.
Человек накосячил, результат работы за неделю в трубу. Его попросили отработать в выходные, восстановить ущерб хотя бы частично. Как по мне — вполне справедливая просьба.
Хотя с ТК она явно не стыкуется, это тоже факт.
Но лично я бы в такой ситуации вышел, за свои поступки надо отвечать (по возможности).
Re[11]: факапы на работе
От: Anton Batenev Россия https://github.com/abbat
Дата: 06.04.17 15:52
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz> D>А в чем проблем сломанной ветки если над ней работает эксклюзивно один разработчик?

Pzz> Меня нервирует сломанная ветка в репозитории.

Чем больше она тебя нервирует, тем быстрее починишь А потом, чтобы не нервировала, объединишь временные коммиты в цельные логические куски.
Re[4]: факапы на работе
От: Gradiens  
Дата: 06.04.17 15:54
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Gradiens, Вы писали:


G>>Здравствуйте, Pavel Dvorkin, Вы писали:


G>>Если фрилансер мне будет рассказывать, что у него накрылся диск — это его проблемы. Я ему посочувствую, но денег не заплачу.

G>>Но штрафовать штатного сотрудника (временем или деньгами), чтобы компенсировать конторе убытки — неверно. Контора же не делится процентом прибыли? Ну так пусть и убытками не делится.

PD>Мне не совсем ясно, в чем разница. А если фрилансер (да хоть кто угодно) принят на срочный договор ? В штате числится, но временно. Контракт на 4 месяца, 3 из них уже прошло, зарплату ему за них платили. А если он принят на договор, но на конкретную работу, без срока ? Где граница ?


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

А с человеком в штате — это трудовые отношения. штатный сотрудник — ни разу ни бизнесмен. Он делает что сказано в рамках своих должностных обязанностей в рабочее время на оборудовании работодателя. Его защищает ТК. Даже если у него срочный договор — его по-прежнему защищает ТК.

Можно подойти и с другой стороны: кто получает прибыль, тот и несет риски. Если хозяин конторы заработает лишний миллион благодаря действиям сотрудников — он же не станет делить этот миллион между ними. Точно также если из-за дейсвий сотрудников он потерял миллион — то сотрудники не должны его компенсировать.
Re[5]: факапы на работе
От: Pavel Dvorkin Россия  
Дата: 06.04.17 16:52
Оценка:
Здравствуйте, Gradiens, Вы писали:

G>Фрилансер — независимый субподрядчик, этакий маленький бизнес из одного человека. Он работает на себя. Он несет риски начиная с неверной оценки сроков и заканчивая сгоревшим оборудованием. Но при этом получает такую прибыль, какую сможет стрясти с заказчика.


G>А с человеком в штате — это трудовые отношения. штатный сотрудник — ни разу ни бизнесмен. Он делает что сказано в рамках своих должностных обязанностей в рабочее время на оборудовании работодателя. Его защищает ТК. Даже если у него срочный договор — его по-прежнему защищает ТК.


Получается, что если с ним заключен договор подряда на разработку, скажем, дизайна сайта (в фирме, допустим, нет дизайнеров, ищем на стороне)

http://www.consultant.ru/document/cons_doc_LAW_9027/416441e14a600610e2ba0765f72cb72c290cdc3c/

то он в твоей интерпретации несет риски, а если для тех же работ его взяли в штат с той же суммой вознаграждения, то уже нет ?
With best regards
Pavel Dvorkin
Re[5]: факапы на работе
От: senglory  
Дата: 06.04.17 20:56
Оценка:
P>>>Я до того как туда попал не знал что такое бывает.

Pzz>>Что заставляет людей оставаться в таких конторах дольше, чем требует ТК?

P>Не знаю честно о всех. Я там проработал около года. Была ипотека и кризис в 2009 году. Сложно было работу найти с нормальной зарплатой. Я там был на позиции Team Lead, платили приемлемо.

А до кризиса было понятно, что руководство там — гандоны? Или пока денег было хоть булками жри, то все шоколадно?
Re[11]: факапы на работе
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 06.04.17 23:58
Оценка: +1
Здравствуйте, ·, Вы писали:

·>Что значит "смешивались"? Просто один и тот же исходник проекта собирается разными компиляторами. Для С/С++ мира это заурядное явление, ничего ни у кого не смешивается.


Ты бы лучше молчал когда деталей не знаешь, за умного сошел бы
Re[8]: факапы на работе
От: Antidote  
Дата: 07.04.17 01:03
Оценка:
Здравствуйте, ·, Вы писали:

·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит. Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.


А patch file не проще создавать и класть на сервер?
Чему бы грабли ни учили, а сердце верит в чудеса.
Re[9]: факапы на работе
От: aik Австралия  
Дата: 07.04.17 02:39
Оценка:
Здравствуйте, Antidote, Вы писали:

A>·>Коммитить и пушить в приватную ветку, а с утра сбрасывать коммит. Уйти домой вечером не оставив бэкапа работы за день — это для меня как уйти из дома, не закрыв входную дверь.

A>А patch file не проще создавать и класть на сервер?

"git add -A ; git push" создает новый хэш и у тебя на сервере будут хэши последних коммитов (видно через git reglog) — полезно если вдруг вспомнил что потерял что то в пределах последних дней-недель (ну, если "git gc" не отрабатывал). С файлами придется или отказаться от фичи, или выдумывать имена (дату туда вхреначивать, например).

Бранчи и репозитории в git просто по-хамски дёшевы чтоб морочиться файловыми патчами. Если у вас нет сервака с гитом — ну купите простейший nas с дебианом или пару (для Надежности) распберипаев с usb дисками
Re[3]: факапы на работе
От: Sammo Россия  
Дата: 07.04.17 02:49
Оценка:
G>А это с какого перепугу?
G>Если он — простой наемный работник, тогда это проблемы работодателя.
Уточню формулировку.
Зарплаты лишить невозможно. По ТК. Но если данный человек хочет получить премию, то ему придется выходить сверхурочно. Это недостаточное обоснование факапа.
И заставить выходить сверхурочно по ТК тоже невозможно.
Кстати, его начальника тоже бы взгреть за неумение наладить рабочий процесс таким образом, чтобы подобное не происходило. Если потеря изменений за неделю, значит человек не коммитился неделю — а это косяк как разработчика, так и его начальника.
Имхо.
Re[10]: факапы на работе
От: Antidote  
Дата: 07.04.17 04:34
Оценка:
Здравствуйте, aik, Вы писали:

aik>"git add -A ; git push" создает новый хэш и у тебя на сервере будут хэши последних коммитов (видно через git reglog) — полезно если вдруг вспомнил что потерял что то в пределах последних дней-недель (ну, если "git gc" не отрабатывал). С файлами придется или отказаться от фичи, или выдумывать имена (дату туда вхреначивать, например).


Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".

Да и редко прям бывает такое, что нечего коммитить, обычно в конце дня всё в бранчах, так что файлы использую редко, без даты. Просто на каждый проект свой файл уже давно есть, перезаписываю и всё. И ни разу пока не приходилось пользоваться этим бэкапом, приходишь и продолжаешь локально работать. А файл так — греет, что если что, то есть


Для потерявшегося кода есть "Local history"
Чему бы грабли ни учили, а сердце верит в чудеса.
Re[11]: факапы на работе
От: · Великобритания  
Дата: 07.04.17 06:49
Оценка: +1
Здравствуйте, Antidote, Вы писали:

aik>>"git add -A ; git push" создает новый хэш и у тебя на сервере будут хэши последних коммитов (видно через git reglog) — полезно если вдруг вспомнил что потерял что то в пределах последних дней-недель (ну, если "git gc" не отрабатывал). С файлами придется или отказаться от фичи, или выдумывать имена (дату туда вхреначивать, например).

A>Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".
Дело привычки. Собственно commit это и есть по сути "патч-файл", только удобно организованный. "не черновиком" он становится только в момент публикации (т.е. push в публичный репо).

A>Да и редко прям бывает такое, что нечего коммитить, обычно в конце дня всё в бранчах, так что файлы использую редко, без даты. Просто на каждый проект свой файл уже давно есть, перезаписываю и всё. И ни разу пока не приходилось пользоваться этим бэкапом, приходишь и продолжаешь локально работать. А файл так — греет, что если что, то есть

Файл можно, конечно, но git удобнее. Набрал две команды: commit/push (или в GUI каком пара кнопок). Всё, готово. Будет автоматом и дата, и описание можно добавить, и история есть, и хранится долго, случайно перезаписать/удалить нельзя. Ещё эти патч-файлы с бинарниками не очень дружат, окажется у тебя какая-нибудь картинка — и патч обломает.

A>Для потерявшегося кода есть "Local history"

local history сложно в другое место перенести, diff сделать и т.п.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[6]: факапы на работе
От: Gradiens  
Дата: 07.04.17 07:22
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Gradiens, Вы писали:


G>>Фрилансер — независимый субподрядчик, этакий маленький бизнес из одного человека. Он работает на себя. Он несет риски начиная с неверной оценки сроков и заканчивая сгоревшим оборудованием. Но при этом получает такую прибыль, какую сможет стрясти с заказчика.


G>>А с человеком в штате — это трудовые отношения. штатный сотрудник — ни разу ни бизнесмен. Он делает что сказано в рамках своих должностных обязанностей в рабочее время на оборудовании работодателя. Его защищает ТК. Даже если у него срочный договор — его по-прежнему защищает ТК.


PD>Получается, что если с ним заключен договор подряда на разработку, скажем, дизайна сайта (в фирме, допустим, нет дизайнеров, ищем на стороне)


PD>http://www.consultant.ru/document/cons_doc_LAW_9027/416441e14a600610e2ba0765f72cb72c290cdc3c/


PD>то он в твоей интерпретации несет риски, а если для тех же работ его взяли в штат с той же суммой вознаграждения, то уже нет ?


Именно так.
Причем, это не в моей интерпретации, это де-юро.
В 705 статье ГК РФ сказано

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


А вТК РФ, Статья 238 сказано

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


То есть, если ты подрядчик — то не важно, сломал ли ты руку, сгорел ли у тебя диск, унесли ли код инопланетяне. Нет результатов — нет печенек.(С) Риски на тебе.
А если ты в штате, то недополученную прибыль из-за потерянного кода возмещать не должен.

Теперь к вопросу оплаты.
Если чел на субподряде попросил столько же денег, сколько штатный сотрудник — сам себе злобный Буратино. Надо учитывать риски.
По личному опыту считаю нормальным повышающий коэффициент от 1.5 до 3-х в зависимости от обстоятельств.
Re[5]: факапы на работе
От: Gradiens  
Дата: 07.04.17 08:28
Оценка: 2 (1)
Здравствуйте, Silver_S, Вы писали:

S_S>Здравствуйте, sharpcoder, Вы писали:



S>>А по закону за это даже посадить можно, если доказать значительный ущерб для работодателя.


S>>Это из УК:

S>>[i]
S>>"Халатность, то есть неисполнение или ненадлежащее исполнение должностным лицом своих обязанностей вследствие недобросовестного или небрежного отношения к службе либо обязанностей по должности, если это повлекло причинение крупного ущерба...
S_S> Случайно допущенные баги это тоже ущерб работодателю, и тоже ненадлежащее исполнение должностным лицом своих обязанностей ....
S_S> Я тоже однажды похерил результаты нескольких дней. В древние времена SourceSafe — точно не помню, второпях не внимательно прочитал вопрос в диалоге, из-за не правильного ответа безвозвратно откатилось назад(похерилось), ...
S_S> Это тоже попадает под статью?

Не подпадает: ТК РФ, Статья 238:
"Работник обязан возместить работодателю причиненный ему прямой действительный ущерб. Неполученные доходы (упущенная выгода) взысканию с работника не подлежат."
Если бы ты комп разбил — то да, это прямой ущерб. А потерял какие-то файлики — это не ущерб, это потеря прибыли работодателя.
Re[12]: факапы на работе
От: landerhigh Пират  
Дата: 07.04.17 09:16
Оценка:
Здравствуйте, John1979, Вы писали:

J>достаточно для чего ?


Чтобы перестать верить, что все можно сделать через инкрементальные изменения и что "код, не собриающийся три дня — признак профнепригодности".

L>>Вообще-то инженерам платят именно за нахождение решений в исключительных случаях. Рутинной работой занимаются кодеры и техподдержка.

J>пальцы растопырить забыл.

За этим в другой чати.
www.blinnov.com
Re[13]: факапы на работе
От: John1979  
Дата: 07.04.17 09:21
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Чтобы перестать верить, что все можно сделать через инкрементальные изменения

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

L> "код, не собриающийся три дня — признак профнепригодности".

1 — не надо мне приписывать то, чего я не говорил
2 — если у кого-то перманентно исключительные ситуации, то этот кто-то либо профнепригоден, либо исключительный разработчик работающий в исключительной компании. вероятность второго стремится к нулю.
Re[14]: факапы на работе
От: landerhigh Пират  
Дата: 07.04.17 09:24
Оценка:
Здравствуйте, John1979, Вы писали:

L>>Чтобы перестать верить, что все можно сделать через инкрементальные изменения

J>кто-то где-то говорил, что абсолютно всё можно сделать инкрементально ?

Ага, не будем показывать пальцем. Товарищ даже что-то про опыт заявлял.

J>тебе четвертый раз повторить про то, что исключительные ситуации рассматривать не имеет смысла ?


А не исключительные ситуации решаются кодерами по пять баксов за пучок.

L>> "код, не собриающийся три дня — признак профнепригодности".

J>1 — не надо мне приписывать то, чего я не говорил

Но ты же участвуешь в этой ветке на стороне аффтара этой фразы, разве нет?

J>2 — если у кого-то перманентно исключительные ситуации, то этот кто-то либо профнепригоден, либо исключительный разработчик работающий в исключительной компании. вероятность второго стремится к нулю.


Либо он просто пишет не очередной опердень, а что-то серьезное.
www.blinnov.com
Re[15]: факапы на работе
От: John1979  
Дата: 07.04.17 09:45
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>Ага, не будем показывать пальцем. Товарищ даже что-то про опыт заявлял.

будь добр зацитировать.

L>Но ты же участвуешь в этой ветке на стороне аффтара этой фразы, разве нет?

мы тут не в футбол играем. чтоб участвовать на каких-то сторонах.

напомню, с чего началось мое участие здесь
'есть мнение, что ситуация, когда у тебя 3 дня лежит код который даже не собирается, не очень нормальна.'

L>Либо он просто пишет не очередной опердень, а что-то серьезное.

очень мне лениво пускаться в меряние письками, начал было писать над чем я работал, да забил.
работай как умеешь.
Re[16]: факапы на работе
От: landerhigh Пират  
Дата: 07.04.17 10:00
Оценка: +1
Здравствуйте, John1979, Вы писали:

J>Здравствуйте, landerhigh, Вы писали:


L>>Ага, не будем показывать пальцем. Товарищ даже что-то про опыт заявлял.

J>будь добр зацитировать.

Вот отсюда
Автор: GarryIV
Дата: 05.04.17

И еше тут
Автор: GarryIV
Дата: 05.04.17


L>>Но ты же участвуешь в этой ветке на стороне аффтара этой фразы, разве нет?

J>мы тут не в футбол играем. чтоб участвовать на каких-то сторонах.

J>напомню, с чего началось мое участие здесь

J>'есть мнение, что ситуация, когда у тебя 3 дня лежит код который даже не собирается, не очень нормальна.'

Мое мнение — ненормальна она разве что при разработке очередных опердней.
Для среднестатистического плюсового проекта с историей такая ситуация весьма вероятна и даже почти неизбежна. И никто из этого не делает сцен и не встает в позу заявлять о профнепригодностях и ненормальностях.

L>>Либо он просто пишет не очередной опердень, а что-то серьезное.

J>очень мне лениво пускаться в меряние письками, начал было писать над чем я работал, да забил.
J>работай как умеешь.

Как умеешь? Я не первый раз прошу научить, как инкрементальными изменениями можно убрать зависимость от глобального объекта, спрятанного за третьей либой. Или осуществить миграцию на новый рантайм. Научите уж пожалуйста, а то я не умею.
www.blinnov.com
Re[6]: факапы на работе
От: playnext  
Дата: 07.04.17 10:13
Оценка:
Здравствуйте, senglory, Вы писали:

P>>>>Я до того как туда попал не знал что такое бывает.


Pzz>>>Что заставляет людей оставаться в таких конторах дольше, чем требует ТК?

P>>Не знаю честно о всех. Я там проработал около года. Была ипотека и кризис в 2009 году. Сложно было работу найти с нормальной зарплатой. Я там был на позиции Team Lead, платили приемлемо.

S>А до кризиса было понятно, что руководство там — гандоны? Или пока денег было хоть булками жри, то все шоколадно?

До кризиса я там не работал. Где я дыт до того, в кризис произошли поэтапные сокрашения большинства отделов.
Та контора по деньгам и позиции была более менее. Быстро найти что то вменяемое в тот кризис было сложновато. К тому же ипотека. Кстати, по наблюдениям того периода, количество гандонов возросло в кризис прямо в геометрической прогрессии.
Re[17]: факапы на работе
От: John1979  
Дата: 07.04.17 10:21
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>>>Ага, не будем показывать пальцем. Товарищ даже что-то про опыт заявлял.

J>>будь добр зацитировать.
L>Вот отсюда
Автор: GarryIV
Дата: 05.04.17

L>И еше тут
Автор: GarryIV
Дата: 05.04.17

какое отношение это имеет к нашей с тобой дискуссии ?

L>Для среднестатистического плюсового проекта с историей такая ситуация весьма вероятна и даже почти неизбежна. И никто из этого не делает сцен и не встает в позу заявлять о профнепригодностях и ненормальностях.

сиутация вероятна и неизбежна, кто это отрицает ?
но как часто ты меняешь тот-же рантайм ? раз в 5-10 лет. а между ними ?

L>Как умеешь? Я не первый раз прошу научить, как инкрементальными изменениями можно убрать зависимость от глобального объекта, спрятанного за третьей либой. Или осуществить миграцию на новый рантайм. Научите уж пожалуйста, а то я не умею.

я тебе в пятый раз повторяю — не цепляйся за исключительные ситуации.
как часто тебе надо заменять криво подключенную ЧУЖУЮ либу, в которой есть зависимость на ТВОЙ глобальный объект ?
не верю, что это является регулярным явлением.
большинство ++ проектов, в которых я участвовал, имели более, чем десятилетнюю историю. одному было около 20 лет.
и такие ломающие всё, глобальные, изменения происходят крайне редко.
Re[18]: факапы на работе
От: landerhigh Пират  
Дата: 07.04.17 10:36
Оценка:
Здравствуйте, John1979, Вы писали:

J>какое отношение это имеет к нашей с тобой дискуссии ?


Самое прямое, оно и начало это дискуссию.

L>>Для среднестатистического плюсового проекта с историей такая ситуация весьма вероятна и даже почти неизбежна. И никто из этого не делает сцен и не встает в позу заявлять о профнепригодностях и ненормальностях.

J>сиутация вероятна и неизбежна, кто это отрицает ?
J>но как часто ты меняешь тот-же рантайм ? раз в 5-10 лет. а между ними ?

Приходилось намного чаще. Когда зависишь от 100500 сторонних либ, приходится решать такие проблемы намного чаще.

L>>Как умеешь? Я не первый раз прошу научить, как инкрементальными изменениями можно убрать зависимость от глобального объекта, спрятанного за третьей либой. Или осуществить миграцию на новый рантайм. Научите уж пожалуйста, а то я не умею.

J>я тебе в пятый раз повторяю — не цепляйся за исключительные ситуации.

Ну так можно любую ситуацию, отличную от чтения кывта, назвать исключительной

J>как часто тебе надо заменять криво подключенную ЧУЖУЮ либу, в которой есть зависимость на ТВОЙ глобальный объект ?


А кто сказал, что объект мой? Объект тоже либе принадлежит. Инициализируется в super_puper_secret_lib::initialize(). Неявно так, тебе даже он и не виден. Но он есть.

J>не верю, что это является регулярным явлением.


Еще раз — ну не платят нам за решение "регулярных проблем". На решенеие регулярных проблем нанимают народ в саппорт. Практически за доширак, как один учаснег этого чати любил выделать восклицательным знаками.
www.blinnov.com
Re[5]: факапы на работе
От: Vladek Россия Github
Дата: 07.04.17 20:17
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Если у меня кусок работы на три дня, и в течении этих трех дней код в промежуточном состоянии не только не работает, но даже и не собирается, что по мнению коллективного фаулера, я должен делать в конце рабочего дня?


Рефакторить ты должен. Бываешь залезешь в такую кодобазу и чтобы добавить какую-то ерунду, надо стопяцот файлов тронуть, да ещё в паре мест забудешь или даже не догадаешься, что тоже надо какой-то ритуальный код вписать, иначе всё сломается.

Три изолированных чекина в день сделать не в состоянии, отдавай каждую написанную строчку на инспекцию старщим товарищам.
Re[11]: факапы на работе
От: Vladek Россия Github
Дата: 07.04.17 20:27
Оценка:
Здравствуйте, landerhigh, Вы писали:

L>В некоторых конторах до сих пор используются недоразумения вроде ClearCase. Это не отменяет того факта, что оттуда нужно как можно быстрее делать ноги, но кроме "сам случайно потер исходники" бывает еще "создал такой merge hell, что приходится все мержить вручную"


А что страшного в мердже? Three-way merge (смотришь base, theirs, yours одновременно) позволят видеть все изменения в файле сразу и делает мердж осознанным. Никогда этого не боялся и никогда не испытывал с этим проблем, поэтому никогда не торопился зачекинить всё раньше коллег.
Re: факапы на работе
От: white_znake  
Дата: 07.04.17 20:44
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Здрасте.


HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


У меня встречный вопрос: а что это за контора, в которой задачи выдают более чем на неделю? Почему нет промежуточного контроля исполнения таких длинных задач?

Ведь, при раздаче длинных задач без контрольных точек, всегда появляется риск, что срок пройдет, а задача так и останется невыполеной.

Виноват тим лид и ПМ. Им работать надо, а не фигней страдать.
Re: факапы на работе
От: vsb Казахстан  
Дата: 07.04.17 20:52
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы.


Потеря памяти? Или текст потерял? Ну так текст набивается быстро. За день набьёт заново.

>И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?


Конечно не норм. Начальника оштрафовать, за то, что упустил тот факт, что человек не коммитит и не бэкапится. Программиста премировать за обнаружение серьёзного упущения в процессах разработки и дать отпуск на неделю, пускай отойдёт от нервного потрясения. По-нормальному так должно быть.
Re[7]: факапы на работе
От: Pavel Dvorkin Россия  
Дата: 08.04.17 04:16
Оценка:
Здравствуйте, Gradiens, Вы писали:

G>Теперь к вопросу оплаты.

G>Если чел на субподряде попросил столько же денег, сколько штатный сотрудник — сам себе злобный Буратино. Надо учитывать риски.
G>По личному опыту считаю нормальным повышающий коэффициент от 1.5 до 3-х в зависимости от обстоятельств.

Хорошо. Давай мысленный эксперимент.

Тебе предлагают некую работу. Как сделать все, что требуется — ты знаешь. Сроки тебя устраивают. Конечно, в ходе работы могут возникнуть изменения, но, допустим, задача достаточно хорошо сформулирована, так что мелкие изменения ее сложность серьезно не повышают, а крупные изменения либо невозможны, либо могут быть предметом дополнительного соглашения во 2 фазе, если она наступит.

Ты согласен.

Тебе предлагают 2 варианта оплаты

1. С тобой заключается договор, сумма вознаграждения N рублей, срок M месяцев.
2. Тебя принимают в штат на M месяцев с зарплатой N/M в месяц. Присутствие в офисе не требуется, рабочий день — по твоему усмотрению, ты лишь должен через M месяцев сделать продукт.

Вопросы, связанные с различным налогообложением, вынесем за скобки. Будем считать, что N — это сумма после уплаты налогов. Возможно, работодатель потратит с учетом налогов разные суммы, но это его проблемы, а не твои.

Я согласен, что юридически это разные варианты, а ну а по существу ? В чем отличие рисков ?
Естественно, я предполагаю, что ты добросовестный исполнитель и не намерен ни получать зарплату по варианту 2 в течение M-1 месяца, ничего не делая, ни получить аванс по варианту 1, а потом исчезнуть.

Я понимаю разницу, если речь идет об изготовлении чего-то материального. В этом случае, конечно, предприниматель должен сам искать поставщика материалов и комплектующих, снимать помещение, нанять работников и т.д., а принятый на работу потребует, чтобы материалы и комплектующие ему предоставил отдел снабжения, а помещение вообще не его забота. Тут у предпринимателя риск — а вдруг детали не найдутся, а вдруг они дороже будут, чем он думал, а вдруг дядя Вася запьет и придется срочно искать кого-то еще.

А у программиста в чем отличия, кроме чисто юридических ?
With best regards
Pavel Dvorkin
Re[3]: факапы на работе
От: denisko http://sdeniskos.blogspot.com/
Дата: 08.04.17 12:46
Оценка:
Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, denisko, Вы писали:


D>>Не, не норм. Просто за эту неделю надо не заплатить и все.


Pzz>Это не законно, между прочим.

Так спрашивали не законно/незаконно, а норм/ненорм. Не заплатить, при определенных условиях, норм, как это провести есть куча способов -- от лобового, который приводил шарпкодер, до особенностей оформления зарплаты (зп + премия) или самого сотрудника (ип). Но все зависит, опять-таки, от конкретной ситуации. Я, если херил, результаты работы, восстанавливал их сам в короткие сроки и по своей инициативе, без того,чтобы кто-то кого-то заставлял.
<Подпись удалена модератором>
Re[8]: факапы на работе
От: Андрей Бабошин Германия http://andreybaboshin.livejournal.com/
Дата: 08.04.17 20:23
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Gradiens, Вы писали:


G>>Теперь к вопросу оплаты.

G>>Если чел на субподряде попросил столько же денег, сколько штатный сотрудник — сам себе злобный Буратино. Надо учитывать риски.
G>>По личному опыту считаю нормальным повышающий коэффициент от 1.5 до 3-х в зависимости от обстоятельств.

PD>Хорошо. Давай мысленный эксперимент.


PD>А у программиста в чем отличия, кроме чисто юридических ?


Отличия только юридические и есть и не завият от профессии.

PD>1. С тобой заключается договор, сумма вознаграждения N рублей, срок M месяцев.


С этих денег сам платишь:
— подоходный налог,
— соц. взносы,
— пенсионные отчисления,
— мед. страховку
— страховка от потери работы, если для ИП в законодательстве страны такая опция есть, если нет: на что будешь жить после окончания контракта — твои проблемы
— прочие налоги,
— ответственность за факапы,
— если в ТЗ (или его подобии) вылезают неточности, то это в т.ч. и твои проблемы.

В случае с РФ/ИП на упрощёнке всё это укладывается, емнип, в 6 %.

PD>2. Тебя принимают в штат на M месяцев с зарплатой N/M в месяц. Присутствие в офисе не требуется, рабочий день — по твоему усмотрению, ты лишь должен через M месяцев сделать продукт.


— подоходный платишь сам,
— соц. взносы, пенсия, всевозможные страховки либо платит работодатель, либо 50/50 (зависит от страны),
— по окончании действия договора можно пойти на биржу труда и получать пособие (размер пособия зависит от страны)
— ответственность только за умышленные действия + преступная халатность
— если по ходу пьесы выясняется, что что-то в начале не было учтено, то это не твои проблемы.

П.С. У меня была подработка, где были фиксированы время и деньги, и мне это не понравилось из-за последнего пункта: всё учесть нельзя, у заказчика появляются новые хотелки, а в той ситуации у меня и манёвра особенно не было.
Re[4]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 00:58
Оценка:
Здравствуйте, sharpcoder, Вы писали:

S>А по закону за это даже посадить можно, если доказать значительный ущерб для работодателя.

Недополученная выгода не является ущербом.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[11]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 01:01
Оценка:
Здравствуйте, Pzz, Вы писали:

D>>А в чем проблем сломанной ветки если над ней работает эксклюзивно один разработчик?

Pzz>Меня нервирует сломанная ветка в репозитории.
Это лучше чем вообще потерять. К тому же она хотя бы историю будет иметь, есть возможность откатиться. А в несуществующей ветке откатиться нельзя.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[6]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 01:03
Оценка:
Здравствуйте, GarryIV, Вы писали:

GIV>Если у человека три дня код в состоянии "не собирается" — коллективный фаулер думает о профнепригодности.

Скорее, об отсутствии банального опыта, что такие ситуации таки случаются и, соответственно, опыта их недопущения/разрешения.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[10]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 01:07
Оценка:
Здравствуйте, ·, Вы писали:

·>С бэкапами почти ничего нельзя интересного сделать.

Как это ничего? А ручками помержить?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[11]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 01:11
Оценка: :)
Здравствуйте, Antidote, Вы писали:

aik>>"git add -A ; git push" создает новый хэш и у тебя на сервере будут хэши последних коммитов (видно через git reglog) — полезно если вдруг вспомнил что потерял что то в пределах последних дней-недель (ну, если "git gc" не отрабатывал). С файлами придется или отказаться от фичи, или выдумывать имена (дату туда вхреначивать, например).

A>Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".
У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[2]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 01:17
Оценка:
Здравствуйте, bazis1, Вы писали:

B>Особенно если сотрудник — один из тех, у которых все вечно не получается, но на каждый случай готов миллион железных оправданий.

Если у компании две недели работы сотрудника стоят его увольнения, то дело скорее в самой компании, чем в сотруднике.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[3]: факапы на работе
От: bazis1 Канада  
Дата: 09.04.17 01:22
Оценка:
Здравствуйте, Vain, Вы писали:

B>>Особенно если сотрудник — один из тех, у которых все вечно не получается, но на каждый случай готов миллион железных оправданий.

V>Если у компании две недели работы сотрудника стоят его увольнения, то дело скорее в самой компании, чем в сотруднике.
Я про то, что эти 2 недели могут быть последней каплей.
Re[4]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 01:25
Оценка:
Здравствуйте, bazis1, Вы писали:

B>>>Особенно если сотрудник — один из тех, у которых все вечно не получается, но на каждый случай готов миллион железных оправданий.

V>>Если у компании две недели работы сотрудника стоят его увольнения, то дело скорее в самой компании, чем в сотруднике.
B>Я про то, что эти 2 недели могут быть последней каплей.
А могут просто ждать причину уволить. Я ни разу не видел подобных сотрудников, чтобы уж совсем совсем плохо. Зато видел таких начальников, которым только дай повод..
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[5]: факапы на работе
От: Андрей Бабошин Германия http://andreybaboshin.livejournal.com/
Дата: 09.04.17 01:43
Оценка:
Здравствуйте, Vain, Вы писали:

V>А могут просто ждать причину уволить. Я ни разу не видел подобных сотрудников, чтобы уж совсем совсем плохо. Зато видел таких начальников, которым только дай повод..


Совсем-совсем плохо обычно выявляется на испытательном сроке. Однако, иногда факапы бывают в управлении и сотрудник успешно проходит испытательный срок (по факту истечения времени)
и вот тут уже начинается акробатика с увольнением.
Re[6]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 02:31
Оценка:
Здравствуйте, Андрей Бабошин, Вы писали:

V>>А могут просто ждать причину уволить. Я ни разу не видел подобных сотрудников, чтобы уж совсем совсем плохо. Зато видел таких начальников, которым только дай повод..

АБ>Совсем-совсем плохо обычно выявляется на испытательном сроке. Однако, иногда факапы бывают в управлении и сотрудник успешно проходит испытательный срок (по факту истечения времени)
АБ>и вот тут уже начинается акробатика с увольнением.
Акробатика с увольнением начинается когда надо сократить, а положенные по закону два месяца платить не хочется.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[11]: факапы на работе
От: · Великобритания  
Дата: 09.04.17 09:10
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>С бэкапами почти ничего нельзя интересного сделать.

V>Как это ничего? А ручками помержить?
Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж? Так что уж очень совсем ручками получается в лучшем случае. В git же одна команда.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: факапы на работе
От: · Великобритания  
Дата: 09.04.17 09:10
Оценка:
Здравствуйте, Vain, Вы писали:

aik>>>"git add -A ; git push" создает новый хэш и у тебя на сервере будут хэши последних коммитов (видно через git reglog) — полезно если вдруг вспомнил что потерял что то в пределах последних дней-недель (ну, если "git gc" не отрабатывал). С файлами придется или отказаться от фичи, или выдумывать имена (дату туда вхреначивать, например).

A>>Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".
V>У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).
Его случайно не Jenkins звали?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[12]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 10:50
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>С бэкапами почти ничего нельзя интересного сделать.

V>>Как это ничего? А ручками помержить?
·>Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж?
Если не так много изменений было, то и не обязательно откатывать. Можно мержить и поверх.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[13]: факапы на работе
От: Vain Россия google.ru
Дата: 09.04.17 10:55
Оценка:
Здравствуйте, ·, Вы писали:

A>>>Мне удобнее видеть незаконченный код незакоммиченным Откатывать коммиты...как-то не очень, коммит — это что-то уже работающее, а не "черновик".

V>>У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).
·>Его случайно не Jenkins звали?
Не, этот был круче в разы. Находил буквально коммиты в последних 10 при количестве тестов в ~600 штук запускающихся каждый не меньше 3 сек и суммарно больше часа. Даже специальная софтина для этого чувака была придумана, где можно было галками подбирать тесты, которые потенциально должны зафейлиться, чтобы не прогонять всё. Дженкинс с таким тогда "лапу" сосал.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re: факапы на работе
От: cosimo http://sapozhnikov.pro
Дата: 09.04.17 16:14
Оценка:
Здравствуйте, HoseCo, Вы писали:

HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Т.е. предлагают еще значительнее увеличить ущерб? До следующего периода отдыха работник выдаст треть своей производительности.
Ребята, я читаю и у меня глаза округляются от вашего срача, как бы похитровывернутее заставить систему контроля версий исполнить роль бэкапа.
Re[12]: факапы на работе
От: Pzz Россия https://github.com/alexpevzner
Дата: 09.04.17 16:49
Оценка:
Здравствуйте, Vain, Вы писали:

Pzz>>Меня нервирует сломанная ветка в репозитории.

V>Это лучше чем вообще потерять. К тому же она хотя бы историю будет иметь, есть возможность откатиться. А в несуществующей ветке откатиться нельзя.

Надо сказать, я в жизни своей ничего не потерял...
Re[3]: факапы на работе
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.04.17 02:02
Оценка:
Здравствуйте, sharpcoder, Вы писали:


S>В пределах месячной заралаты может быть ответственность легко, в данном случае можно лишить недельной заралаты за такое.

S>http://base.garant.ru/12125268/39/#friends

К случаю топикстартера не относится. Это не материальный ущерб. Даже "материализовать" его невозможно.
Re[8]: факапы на работе
От: Gradiens  
Дата: 10.04.17 08:44
Оценка: +2
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, Gradiens, Вы писали:


G>>Теперь к вопросу оплаты.

G>>Если чел на субподряде попросил столько же денег, сколько штатный сотрудник — сам себе злобный Буратино. Надо учитывать риски.
G>>По личному опыту считаю нормальным повышающий коэффициент от 1.5 до 3-х в зависимости от обстоятельств.

PD>Хорошо. Давай мысленный эксперимент.


PD>Тебе предлагают некую работу. Как сделать все, что требуется — ты знаешь. Сроки тебя устраивают. Конечно, в ходе работы могут возникнуть изменения, но, допустим, задача достаточно хорошо сформулирована, так что мелкие изменения ее сложность серьезно не повышают, а крупные изменения либо невозможны, либо могут быть предметом дополнительного соглашения во 2 фазе, если она наступит.


PD>Ты согласен.


PD>Тебе предлагают 2 варианта оплаты


PD>1. С тобой заключается договор, сумма вознаграждения N рублей, срок M месяцев.

PD>2. Тебя принимают в штат на M месяцев с зарплатой N/M в месяц. Присутствие в офисе не требуется, рабочий день — по твоему усмотрению, ты лишь должен через M месяцев сделать продукт.

PD>Вопросы, связанные с различным налогообложением, вынесем за скобки. Будем считать, что N — это сумма после уплаты налогов. Возможно, работодатель потратит с учетом налогов разные суммы, но это его проблемы, а не твои.


Вопросы, связанные с налогами тяжело вынести за скобки.
У работодателя/заказчика есть бюджет, в который надо вписаться. Сколько из этого бюджета получишь лично ты, а сколько уйдет в налоги — ему пофиг. Это тебе не пофиг. Грубо, очень грубо, при тех же затратах заказчика ты получишь на треть больше, если ты — ИП, а не штатный сотрудник.
То есть хотя бы из этого можно просить больше )

PD>Я согласен, что юридически это разные варианты, а ну а по существу ? В чем отличие рисков ?

PD>Естественно, я предполагаю, что ты добросовестный исполнитель и не намерен ни получать зарплату по варианту 2 в течение M-1 месяца, ничего не делая, ни получить аванс по варианту 1, а потом исчезнуть.

Так по существу отличие в том, кто несет риски.
Повторюсь, штатный сотрудник несет намного, намного меньше рисков чем, скажем, ИП-шник на субподряде.

Примеры:
Исполнитель заболел.
Если он — сотрудник — ничего не попишешь. Придется ему оплачивать больничный (небольшой, но все же), и сдвигать сроки.
Если он — подрядчик — никто ничего ему не оплатит. К тому же придется ему потом впахивать сверхурочно чтобы наверстать упущенное.

У работодателя что-то изменилось/добаваилось в требованиях. (А это происходит всегда. Видимо, расширение объема работ — это некий закон природы, постоянный как расширение вселенной)
Для сотрудника либо работодатель продлит контракт, либо останется с обрезанным функционалом.
Для подрядчика — надо с боем сопротивляться всем изменениям, или с боем выгрызать для них оплату.

Оказалось, оценка сроков/сложности неверна. Не важно, чья это ошибка. Но это — самая распостраненная ошибка даже для очень опытных. Нельзя дать сколько-нибудь точную оценку большому проекту. Это как по моему скромному опыту, так и по мнению многих классиков, от Де Марко до Спольски.
Для сотрудника — то же что и в предыдущем пункте. Честно работает, пока контракт не закончится. Закончил работу раньше — молодец, сиди кури бамбук, зарплата идет. Но это бывает редко. Чаще — закончилось время, а проект по объективным причинам не готов. И заказчик либо платит еще, либо хоронит недоделанный проект.
Для подрядчика — это его риск. Не успел — работай дальше без оплаты, пока не доделаешь. Да еще, как правило, попадаешь на пени.

Ах, да, надеюсь, никто не забыл, что если ты ИП-шник, то отвечаешь своим имуществом? В случае колоссальных продолбов наемный работник просто увольняется, а вот ИП-шник останется без последней рубашки. От продолбов никто не застрахован.


PD>Я понимаю разницу, если речь идет об изготовлении чего-то материального. В этом случае, конечно, предприниматель должен сам искать поставщика материалов и комплектующих, снимать помещение, нанять работников и т.д., а принятый на работу потребует, чтобы материалы и комплектующие ему предоставил отдел снабжения, а помещение вообще не его забота. Тут у предпринимателя риск — а вдруг детали не найдутся, а вдруг они дороже будут, чем он думал, а вдруг дядя Вася запьет и придется срочно искать кого-то еще.


Вот в случае чего-то материального бывают даже более простые ситуации. Допустим, ты профессиональный резчик матрешек — ты прекрасно знаешь свою производитльность, и можешь оценить риски с поставщиками и т.д. То есть ты понимаешь, за сколько ты вырежешь 10000 матрешек.
А если ты профессиональный разработчик в ентерпрайзе — ну не сможешь ты оценить серьезный проект с приемлемой для заказчика точностью. Даже мелкие задачи могут легко расходится с оценкой в два раза.

PD>А у программиста в чем отличия, кроме чисто юридических ?

Так что, в итоге, отличия в том, кто несет риск не только де-юре, но и де-факто.
Re[13]: факапы на работе
От: · Великобритания  
Дата: 10.04.17 08:58
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>·>С бэкапами почти ничего нельзя интересного сделать.

V>>>Как это ничего? А ручками помержить?
V>·>Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж?
V>Если не так много изменений было, то и не обязательно откатывать. Можно мержить и поверх.
А "много" это сколько? А если таки "много"? А как собственно бэкап восстановить? Как запустить мержилку? А эта мержилка есть интегрированная в твою любимую IDE?
Ты вроде обещал "проще", а внезапно столько неудобных вопросов возникает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[14]: факапы на работе
От: · Великобритания  
Дата: 10.04.17 09:04
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>У нас в конторе на одной работе был специальный чувак, у которого с утра была одна задача, найти нестабильные коммиты и откатить их. Многие его за это недолюбливали, только был он далеко от офиса (наверно на всякий случай).

V>·>Его случайно не Jenkins звали?
V>Не, этот был круче в разы. Находил буквально коммиты в последних 10 при количестве тестов в ~600 штук запускающихся каждый не меньше 3 сек и суммарно больше часа. Даже специальная софтина для этого чувака была придумана, где можно было галками подбирать тесты, которые потенциально должны зафейлиться, чтобы не прогонять всё. Дженкинс с таким тогда "лапу" сосал.
У нас этим кластер занимается. 10к тестов (некоторые довольно медленные) — но на сотне многопроцессорных серваках выполняется за 15мин — уже реально проверять почти каждый коммит. А если была пачка коммитов одновременно, то практически всегда очевидно какой из этих ~5 коммитов завалил конкретный тест.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[9]: факапы на работе
От: Pavel Dvorkin Россия  
Дата: 10.04.17 14:39
Оценка:
Здравствуйте, Gradiens, Вы писали:

Не скажу, что ты меня убедил на 100%, но определенная логика в твоих соображениях есть, признаю.
With best regards
Pavel Dvorkin
Re[8]: факапы на работе
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 10.04.17 15:20
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Тебе предлагают некую работу. Как сделать все, что требуется — ты знаешь. Сроки тебя устраивают. Конечно, в ходе работы могут возникнуть изменения, но, допустим, задача достаточно хорошо сформулирована, так что мелкие изменения ее сложность серьезно не повышают, а крупные изменения либо невозможны, либо могут быть предметом дополнительного соглашения во 2 фазе, если она наступит.


PD>Тебе предлагают 2 варианта оплаты

PD>1. С тобой заключается договор, сумма вознаграждения N рублей, срок M месяцев.
PD>2. Тебя принимают в штат на M месяцев с зарплатой N/M в месяц. Присутствие в офисе не требуется, рабочий день — по твоему усмотрению, ты лишь должен через M месяцев сделать продукт.

В первом случае ты можешь не получить сумму N вообще, а еще можешь неограниченно долго облизывать заказчика, чтобы он акты подписал. Плюс еще геморрой собственно выбить деньги.
Во втором случае ты гарантированно получаешь сумму N за M месяцев, независимо от реального результата. А еще тебе отпуск начисляется если ты более 6 месяцев работаешь и при увольнении должны выплатить компенсацию.

PD>А у программиста в чем отличия, кроме чисто юридических ?

Вот и считай что тебе выгоднее.
Re[14]: факапы на работе
От: Vain Россия google.ru
Дата: 10.04.17 18:44
Оценка:
Здравствуйте, ·, Вы писали:

V>>>>·>С бэкапами почти ничего нельзя интересного сделать.

V>>>>Как это ничего? А ручками помержить?
V>>·>Для мержа нужен 3-side, а бэкапы линейные. Т.е. основной юзкейс это "откатиться до бекапа на дату D", откуда там мерж?
V>>Если не так много изменений было, то и не обязательно откатывать. Можно мержить и поверх.
·>А "много" это сколько? А если таки "много"? А как собственно бэкап восстановить? Как запустить мержилку?
Господа программисты разучились бекапить и мержить руками? Везде вам рюшечношашечная ИДЕ подавай? А как ты думаешь по-твоему мержили без любименькой VCS?

V>А эта мержилка есть интегрированная в твою любимую IDE?

А нафиг оно надо?

·>Ты вроде обещал "проще", а внезапно столько неудобных вопросов возникает.

Я проще не обещал, а вот хоть как-то будет.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[15]: факапы на работе
От: Vain Россия google.ru
Дата: 10.04.17 18:46
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>Его случайно не Jenkins звали?

V>>Не, этот был круче в разы. Находил буквально коммиты в последних 10 при количестве тестов в ~600 штук запускающихся каждый не меньше 3 сек и суммарно больше часа. Даже специальная софтина для этого чувака была придумана, где можно было галками подбирать тесты, которые потенциально должны зафейлиться, чтобы не прогонять всё. Дженкинс с таким тогда "лапу" сосал.
·>У нас этим кластер занимается. 10к тестов (некоторые довольно медленные) — но на сотне многопроцессорных серваках выполняется за 15мин — уже реально проверять почти каждый коммит.
Не, чувак с инструментом дешевле стоил.

·>А если была пачка коммитов одновременно, то практически всегда очевидно какой из этих ~5 коммитов завалил конкретный тест.

Очевидно, не очевидно, а искать всё равно надо, повторно прогоняя и анализируя результат.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[6]: факапы на работе
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 10.04.17 19:31
Оценка:
Здравствуйте, John1979, Вы писали:

J>есть мнение, что ситуация, когда у тебя 3 дня лежит код который даже не собирается, не очень нормальна.


У меня бывает неработающий код лежит на рабочем ноуте две-три недели — точнее, он непроверенный — мож работает, а мож и нет
[КУ] оккупировала армия.
Re[7]: факапы на работе
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 10.04.17 19:33
Оценка:
Здравствуйте, Vain, Вы писали:

V>Скорее, об отсутствии банального опыта, что такие ситуации таки случаются и, соответственно, опыта их недопущения/разрешения.

Фигня. В начале нового проекта подобная ситуация совсем нередка, ибо обычно педалится каркас приложения, и бывает, что неделями код представляет из себя тонну слабосвязанных двуг с другом "инфраструктурных" классов.
[КУ] оккупировала армия.
Re[6]: факапы на работе
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 10.04.17 19:43
Оценка:
Здравствуйте, Андрей Бабошин, Вы писали:

АБ>Совсем-совсем плохо обычно выявляется на испытательном сроке. Однако, иногда факапы бывают в управлении и сотрудник успешно проходит испытательный срок (по факту истечения времени)

Как раз такие "инфраструктурные" факапы на испытательном сроке совсем не удивительны, т.к. человек ещё не знает, как тут и что принято. А если устроить 100500 часов тренингов для новичком, как делают некоторые конторы, то после их окончания у человека будет такая каша в голове, что лучше его вообще к коду не подпускать первое время после них Эта проблема особенно остро стоит в публичных компаниях, т.к. правила многих бирж требуют обязательного прохождения определённых тренингов по insider trading, плюс в зависимости от типа бизнеса могут быть похожие требования, установленные законом (например в банках у нас требуют проходить "антиотмывочные" тренинги, на которых скорее учат, как отмывать бабло, а не как с этим бороться ).
[КУ] оккупировала армия.
Re[4]: факапы на работе
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 10.04.17 19:44
Оценка:
Здравствуйте, bazis1, Вы писали:

B>Я про то, что эти 2 недели могут быть последней каплей.

Тогда это не причина, а повод.
[КУ] оккупировала армия.
Re[8]: факапы на работе
От: Vain Россия google.ru
Дата: 10.04.17 20:09
Оценка:
Здравствуйте, koandrew, Вы писали:

V>>Скорее, об отсутствии банального опыта, что такие ситуации таки случаются и, соответственно, опыта их недопущения/разрешения.

K>Фигня. В начале нового проекта подобная ситуация совсем нередка, ибо обычно педалится каркас приложения, и бывает, что неделями код представляет из себя тонну слабосвязанных двуг с другом "инфраструктурных" классов.
А я не про "жертву" говорил. А про читак апеллирующим ко всяким фаулерам без банально своего опыта за плечами.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[9]: факапы на работе
От: koandrew Канада http://thingselectronic.blogspot.ca/
Дата: 10.04.17 20:16
Оценка:
Здравствуйте, Vain, Вы писали:

V>А я не про "жертву" говорил. А про читак апеллирующим ко всяким фаулерам без банально своего опыта за плечами.

Ну с теми, кому мозги заменили на догмы, как бы и так всё понятно Чего тут обсуждать-то?
[КУ] оккупировала армия.
Re[15]: факапы на работе
От: · Великобритания  
Дата: 10.04.17 20:16
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>А "много" это сколько? А если таки "много"? А как собственно бэкап восстановить? Как запустить мержилку?

V>Господа программисты разучились бекапить и мержить руками? Везде вам рюшечношашечная ИДЕ подавай? А как ты думаешь по-твоему мержили без любименькой VCS?
У нас тут кружок умелые ручки что-ли? Может сразу на перфокартах набивать?

V>>А эта мержилка есть интегрированная в твою любимую IDE?

V>А нафиг оно надо?
Удобнее и эффективнее.

V>·>Ты вроде обещал "проще", а внезапно столько неудобных вопросов возникает.

V>Я проще не обещал, а вот хоть как-то будет.
О! А у меня идея! Попробуй ещё мержить в противогазе, стоя на гамаке.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[16]: факапы на работе
От: Vain Россия google.ru
Дата: 10.04.17 20:27
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>А "много" это сколько? А если таки "много"? А как собственно бэкап восстановить? Как запустить мержилку?

V>>Господа программисты разучились бекапить и мержить руками? Везде вам рюшечношашечная ИДЕ подавай? А как ты думаешь по-твоему мержили без любименькой VCS?
·>У нас тут кружок умелые ручки что-ли? Может сразу на перфокартах набивать?
Ну раз ты готов ради лени просто скопировать работу — потерять работу, можешь не набивать.

V>>>А эта мержилка есть интегрированная в твою любимую IDE?

V>>А нафиг оно надо?
·>Удобнее и эффективнее.
Удобнее и эффективнее но потерять, по сравнению с небольшим неудобствами и сохранить? Выбираю второе.

V>>Я проще не обещал, а вот хоть как-то будет.

·>О! А у меня идея! Попробуй ещё мержить в противогазе, стоя на гамаке.
Я не понимаю почему у тебя это вызывает такую боль? Боишься что засмеют?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[17]: факапы на работе
От: · Великобритания  
Дата: 10.04.17 20:37
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Господа программисты разучились бекапить и мержить руками? Везде вам рюшечношашечная ИДЕ подавай? А как ты думаешь по-твоему мержили без любименькой VCS?

V>·>У нас тут кружок умелые ручки что-ли? Может сразу на перфокартах набивать?
V>Ну раз ты готов ради лени просто скопировать работу — потерять работу, можешь не набивать.
Я ради лени не хочу использовать неудобные инструменты. "Скопировать работу" это просто сделать push в приватный бранч (хоть из IDE, хоть из cli, хоть из спец-тулзы, как удобнее). Не нужны никакие бэкапы.

V>·>Удобнее и эффективнее.

V>Удобнее и эффективнее но потерять, по сравнению с небольшим неудобствами и сохранить? Выбираю второе.
А я выбираю третье — удобно сохранить.

V>>>Я проще не обещал, а вот хоть как-то будет.

V>·>О! А у меня идея! Попробуй ещё мержить в противогазе, стоя на гамаке.
V>Я не понимаю почему у тебя это вызывает такую боль? Боишься что засмеют?
Аж кушать не могу.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[18]: факапы на работе
От: Vain Россия google.ru
Дата: 10.04.17 21:58
Оценка:
Здравствуйте, ·, Вы писали:

V>>Ну раз ты готов ради лени просто скопировать работу — потерять работу, можешь не набивать.

·>Я ради лени не хочу использовать неудобные инструменты. "Скопировать работу" это просто сделать push в приватный бранч (хоть из IDE, хоть из cli, хоть из спец-тулзы, как удобнее). Не нужны никакие бэкапы.
А если не можешь сделать push по какой-то причине?

V>>Удобнее и эффективнее но потерять, по сравнению с небольшим неудобствами и сохранить? Выбираю второе.

·>А я выбираю третье — удобно сохранить.
Опять возвращаемся к вопросу о присутствии возможности сохранить удобно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[19]: факапы на работе
От: · Великобритания  
Дата: 10.04.17 22:05
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>Я ради лени не хочу использовать неудобные инструменты. "Скопировать работу" это просто сделать push в приватный бранч (хоть из IDE, хоть из cli, хоть из спец-тулзы, как удобнее). Не нужны никакие бэкапы.

V>А если не можешь сделать push по какой-то причине?
По какой, например?

V>>>Удобнее и эффективнее но потерять, по сравнению с небольшим неудобствами и сохранить? Выбираю второе.

V>·>А я выбираю третье — удобно сохранить.
V>Опять возвращаемся к вопросу о присутствии возможности сохранить удобно.
В git эта возможность всегда присутствует.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[20]: факапы на работе
От: Vain Россия google.ru
Дата: 10.04.17 22:19
Оценка:
Здравствуйте, ·, Вы писали:

V>>А если не можешь сделать push по какой-то причине?

·>По какой, например?
Запрет на залив нерабочего кода или кодревью какой?

V>>·>А я выбираю третье — удобно сохранить.

V>>Опять возвращаемся к вопросу о присутствии возможности сохранить удобно.
·>В git эта возможность всегда присутствует.
Технически, но не административно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[21]: факапы на работе
От: · Великобритания  
Дата: 10.04.17 22:28
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>А если не можешь сделать push по какой-то причине?

V>·>По какой, например?
V>Запрет на залив нерабочего кода или кодревью какой?
Приватный репо же, можешь тупо на любой сетевой шаре или по ssh сам сделать.


V>·>В git эта возможность всегда присутствует.

V>Технически, но не административно.
Но при этом бэкап разрешён? Ну поставь этот приватный репо в то место, которое бэкапится.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[22]: факапы на работе
От: Vain Россия google.ru
Дата: 11.04.17 21:36
Оценка:
Здравствуйте, ·, Вы писали:

V>>>>А если не можешь сделать push по какой-то причине?

V>>·>По какой, например?
V>>Запрет на залив нерабочего кода или кодревью какой?
·>Приватный репо же, можешь тупо на любой сетевой шаре или по ssh сам сделать.
Так речь про удалённый а не локальный. К тому же мир на гите что ли сошёлся?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[23]: факапы на работе
От: · Великобритания  
Дата: 12.04.17 19:10
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>>>А если не можешь сделать push по какой-то причине?

V>>>·>По какой, например?
V>>>Запрет на залив нерабочего кода или кодревью какой?
V>·>Приватный репо же, можешь тупо на любой сетевой шаре или по ssh сам сделать.
V>Так речь про удалённый а не локальный.
Ты о чём? Который удалённый? В чём проблема иметь приватный репо для бэкапов?

V>К тому же мир на гите что ли сошёлся?

Уж несколько лет как сошелся, остальные мирно дохнут.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[24]: факапы на работе
От: Vain Россия google.ru
Дата: 12.04.17 22:46
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>Приватный репо же, можешь тупо на любой сетевой шаре или по ssh сам сделать.

V>>Так речь про удалённый а не локальный.
·>Ты о чём? Который удалённый? В чём проблема иметь приватный репо для бэкапов?
Который не у тебя на компе. Притом что я уже сказал, что он не должен быть несобирающийся, к примеру. Или должен быть пройден через ревью, а приватный/неприватный это дело десятое.

V>>К тому же мир на гите что ли сошёлся?

·>Уж несколько лет как сошелся, остальные мирно дохнут.
Кто вам сказал такую глупость?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[25]: факапы на работе
От: · Великобритания  
Дата: 13.04.17 09:15
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Так речь про удалённый а не локальный.

V>·>Ты о чём? Который удалённый? В чём проблема иметь приватный репо для бэкапов?
V>Который не у тебя на компе. Притом что я уже сказал, что он не должен быть несобирающийся, к примеру. Или должен быть пройден через ревью, а приватный/неприватный это дело десятое.
Ты точно понимаешь смысл слова "приватный"? Это означает "личный", тот который твой. Окуда там возьмутся ревью или требование собираемости?
Даже если админы не позаботились о per-developer песочницах под приватные ветки в центральном репо-менеджере вашей компании, то тебе ничего не мешает набрать "git init" самому.

V>>>К тому же мир на гите что ли сошёлся?

V>·>Уж несколько лет как сошелся, остальные мирно дохнут.
V>Кто вам сказал такую глупость?
https://trends.google.com/trends/explore?date=all&amp;q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F08w6d6,%2Fm%2F09d6g&amp;hl=en-US
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 13.04.2017 9:15 · . Предыдущая версия .
Re[26]: факапы на работе
От: Vain Россия google.ru
Дата: 13.04.17 19:43
Оценка:
Здравствуйте, ·, Вы писали:

V>>Который не у тебя на компе. Притом что я уже сказал, что он не должен быть несобирающийся, к примеру. Или должен быть пройден через ревью, а приватный/неприватный это дело десятое.

·>Ты точно понимаешь смысл слова "приватный"? Это означает "личный", тот который твой. Окуда там возьмутся ревью или требование собираемости?
·>Даже если админы не позаботились о per-developer песочницах под приватные ветки в центральном репо-менеджере вашей компании, то тебе ничего не мешает набрать "git init" самому.
Так сервер заводишь не ты а компания, и правила не твои а компании.

V>>>>К тому же мир на гите что ли сошёлся?

V>>·>Уж несколько лет как сошелся, остальные мирно дохнут.
V>>Кто вам сказал такую глупость?
·>https://trends.google.com/trends/explore?date=all&amp;q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F08w6d6,%2Fm%2F09d6g&amp;hl=en-US
А где там дохнут? Я вижу рост опенсоурс репозиториев. Есть такой же график для коммерческих реп?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[27]: факапы на работе
От: · Великобритания  
Дата: 13.04.17 20:25
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>Ты точно понимаешь смысл слова "приватный"? Это означает "личный", тот который твой. Окуда там возьмутся ревью или требование собираемости?

V>·>Даже если админы не позаботились о per-developer песочницах под приватные ветки в центральном репо-менеджере вашей компании, то тебе ничего не мешает набрать "git init" самому.
V>Так сервер заводишь не ты а компания, и правила не твои а компании.
Какой сервер?

V>>>Кто вам сказал такую глупость?

V>·>https://trends.google.com/trends/explore?date=all&amp;q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F08w6d6,%2Fm%2F09d6g&amp;hl=en-US
V>А где там дохнут? Я вижу рост опенсоурс репозиториев. Есть такой же график для коммерческих реп?
Это тренд "Interest over time", а не просто "опенсорс".
Можешь тут посмотреть ещё: https://www.quora.com/What-version-control-systems-do-large-companies-use
Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[28]: факапы на работе
От: Vain Россия google.ru
Дата: 13.04.17 20:41
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>Ты точно понимаешь смысл слова "приватный"? Это означает "личный", тот который твой. Окуда там возьмутся ревью или требование собираемости?

V>>·>Даже если админы не позаботились о per-developer песочницах под приватные ветки в центральном репо-менеджере вашей компании, то тебе ничего не мешает набрать "git init" самому.
V>>Так сервер заводишь не ты а компания, и правила не твои а компании.
·>Какой сервер?
По новому кругу идём?

V>>>>Кто вам сказал такую глупость?

V>>·>https://trends.google.com/trends/explore?date=all&amp;q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F08w6d6,%2Fm%2F09d6g&amp;hl=en-US
V>>А где там дохнут? Я вижу рост опенсоурс репозиториев. Есть такой же график для коммерческих реп?
·>Это тренд "Interest over time", а не просто "опенсорс".
Это тренд в интернете для опенсоурс софта который общедоступен. Какое это отношение имеет к коммерческому софту и репам к ним?

·>Можешь тут посмотреть ещё: https://www.quora.com/What-version-control-systems-do-large-companies-use

Ну и где там дохнет то?

·>Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.

Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe. EA — perforce. Достаточно крупные компании для тебя?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[29]: факапы на работе
От: · Великобритания  
Дата: 13.04.17 21:34
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>·>Ты точно понимаешь смысл слова "приватный"? Это означает "личный", тот который твой. Окуда там возьмутся ревью или требование собираемости?

V>>>·>Даже если админы не позаботились о per-developer песочницах под приватные ветки в центральном репо-менеджере вашей компании, то тебе ничего не мешает набрать "git init" самому.
V>>>Так сервер заводишь не ты а компания, и правила не твои а компании.
V>·>Какой сервер?
V>По новому кругу идём?
Я просто не понимаю что ты пытаешься сказать. Я говорю "приватный репо", а ты мне "заводит сервер компания". Какая взаимосвязь? Какой сервер? На кой приватному репо какой-то сервер?

V>>>·>https://trends.google.com/trends/explore?date=all&amp;q=%2Fm%2F05vqwg,%2Fm%2F012ct9,%2Fm%2F08441_,%2Fm%2F08w6d6,%2Fm%2F09d6g&amp;hl=en-US

V>>>А где там дохнут? Я вижу рост опенсоурс репозиториев. Есть такой же график для коммерческих реп?
V>·>Это тренд "Interest over time", а не просто "опенсорс".
V>Это тренд в интернете для опенсоурс софта который общедоступен. Какое это отношение имеет к коммерческому софту и репам к ним?
Да с чего ты взял? Работник коммерческой компании тоже имеет "Interest" к некой vcs, если компания использует эту vcs.
Да и не просто "рост опенсоурс репозиториев", а именно переезд на git. Поинтересуйся судьбой sourceforge и bitbucket.
Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.

V>·>Можешь тут посмотреть ещё: https://www.quora.com/What-version-control-systems-do-large-companies-use

V>Ну и где там дохнет то?
Он там в почти в каждой строчке. Ещё лет 5 назад такого не было. И он, как правило, частично замещает существующие vcs.

V>·>Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.

V>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe.
TFS вообще-то не vcs. TFS может использовать и git. Ты наверное с TFVC попутал. А так с недавнего времени (мы ж о трендах?) внезапно: "Git is the default version control provider for new projects".

V>EA — perforce. Достаточно крупные компании для тебя?

Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: факапы на работе
От: landerhigh Пират  
Дата: 13.04.17 21:48
Оценка: +1
Здравствуйте, ·, Вы писали:


V>>По новому кругу идём?

·>Я просто не понимаю что ты пытаешься сказать. Я говорю "приватный репо", а ты мне "заводит сервер компания". Какая взаимосвязь? Какой сервер? На кой приватному репо какой-то сервер?

Не напрягайся, человек, очевидно, ничего про git не знает.

·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.


Оймля... ClearCase. Опять кошмары будут сниться.
www.blinnov.com
Re[30]: факапы на работе
От: Vain Россия google.ru
Дата: 14.04.17 00:39
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>Какой сервер?

V>>По новому кругу идём?
·>Я просто не понимаю что ты пытаешься сказать. Я говорю "приватный репо", а ты мне "заводит сервер компания". Какая взаимосвязь? Какой сервер? На кой приватному репо какой-то сервер?
На той, что работу легко как раз похерить локально.

V>>Это тренд в интернете для опенсоурс софта который общедоступен. Какое это отношение имеет к коммерческому софту и репам к ним?

·>Да с чего ты взял? Работник коммерческой компании тоже имеет "Interest" к некой vcs, если компания использует эту vcs.
Он может всё что угодно иметь, каким образом статистика собирается то?

·>Да и не просто "рост опенсоурс репозиториев", а именно переезд на git. Поинтересуйся судьбой sourceforge и bitbucket.

sourceforge опенсоурс. bitbucket вообще платный.

·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.

А я не наблюдал, дальше что?

V>>·>Можешь тут посмотреть ещё: https://www.quora.com/What-version-control-systems-do-large-companies-use

V>>Ну и где там дохнет то?
·>Он там в почти в каждой строчке. Ещё лет 5 назад такого не было. И он, как правило, частично замещает существующие vcs.
Что он там замещает то? Как, к примеру, гит заменит ревизии в свн? Или простоту использования последнего?

V>>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe.

·>TFS вообще-то не vcs. TFS может использовать и git. Ты наверное с TFVC попутал. А так с недавнего времени (мы ж о трендах?) внезапно: "Git is the default version control provider for new projects".
Это маркетинг.

V>>EA — perforce. Достаточно крупные компании для тебя?

·>Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.
разве github не отказались от annex в пользу lfs?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[31]: факапы на работе
От: Vain Россия google.ru
Дата: 14.04.17 00:41
Оценка:
Здравствуйте, landerhigh, Вы писали:

V>>>По новому кругу идём?

L>·>Я просто не понимаю что ты пытаешься сказать. Я говорю "приватный репо", а ты мне "заводит сервер компания". Какая взаимосвязь? Какой сервер? На кой приватному репо какой-то сервер?
L>Не напрягайся, человек, очевидно, ничего про git не знает.
а человек видимо знает про свн чтобы утверждать что он подохнет?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[31]: факапы на работе
От: · Великобритания  
Дата: 14.04.17 17:14
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>По новому кругу идём?

V>·>Я просто не понимаю что ты пытаешься сказать. Я говорю "приватный репо", а ты мне "заводит сервер компания". Какая взаимосвязь? Какой сервер? На кой приватному репо какой-то сервер?
V>На той, что работу легко как раз похерить локально.
Так какой сервер-то? Counter Strike Server подойдёт?

V>>>Это тренд в интернете для опенсоурс софта который общедоступен. Какое это отношение имеет к коммерческому софту и репам к ним?

V>·>Да с чего ты взял? Работник коммерческой компании тоже имеет "Interest" к некой vcs, если компания использует эту vcs.
V>Он может всё что угодно иметь, каким образом статистика собирается то?
Если факты тебе не нравятся — тем хуже для фактов... Ок, приведи другие данные, котоые собраны более удобным для тебя способом.

V>·>Да и не просто "рост опенсоурс репозиториев", а именно переезд на git. Поинтересуйся судьбой sourceforge и bitbucket.

V>sourceforge опенсоурс.
Большое число проектов с sourceforge переехали в github.

V>bitbucket вообще платный.

"Free for small teams." Но суть в том, что его переделали с hg на git.

V>·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.

V>А я не наблюдал, дальше что?
А ты наблюдал переезды обратно?

V>>>Ну и где там дохнет то?

V>·>Он там в почти в каждой строчке. Ещё лет 5 назад такого не было. И он, как правило, частично замещает существующие vcs.
V>Что он там замещает то?
Существующие vcs.

V>Как, к примеру, гит заменит ревизии в свн?

git describe, build numbers, etc.

V>Или простоту использования последнего?

Давно уж заменил.

V>>>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe.

V>·>TFS вообще-то не vcs. TFS может использовать и git. Ты наверное с TFVC попутал. А так с недавнего времени (мы ж о трендах?) внезапно: "Git is the default version control provider for new projects".
V>Это маркетинг.
Маркетинг чего? Линус проплатил Майкрософту?!

V>>>EA — perforce. Достаточно крупные компании для тебя?

V>·>Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.
V>разве github не отказались от annex в пользу lfs?
Ах, ну раз lfs — это всё менят!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: факапы на работе
От: Vain Россия google.ru
Дата: 14.04.17 19:50
Оценка:
Здравствуйте, ·, Вы писали:

V>>На той, что работу легко как раз похерить локально.

·>Так какой сервер-то? Counter Strike Server подойдёт?
Удалённый. Но ты продолжай ёрничать.

V>>Он может всё что угодно иметь, каким образом статистика собирается то?

·>Если факты тебе не нравятся — тем хуже для фактов...
Какие факты, пока что одни интерпретации.

·>Ок, приведи другие данные, котоые собраны более удобным для тебя способом.

Ты издеваешься или действительно не понимаешь что их просто не собрать?

V>>sourceforge опенсоурс.

·>Большое число проектов с sourceforge переехали в github.
Видел там и там.

V>>·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.

V>>А я не наблюдал, дальше что?
·>А ты наблюдал переезды обратно?
Оупенсоурс в прайват? И как её можно наблюдать?

V>>·>Он там в почти в каждой строчке. Ещё лет 5 назад такого не было. И он, как правило, частично замещает существующие vcs.

V>>Что он там замещает то?
·>Существующие vcs.
Но они живее всех живых.

V>>Как, к примеру, гит заменит ревизии в свн?

·>git describe, build numbers, etc.
https://pukkaone.github.io/2010/12/19/build-number-git-repository.html
Куча каких то левых операций сделать чтобы только билд номер посмотреть? В свн это вообще из каропки и ничего не надо делать. Даже теги не надо ставить.

V>>Или простоту использования последнего?

·>Давно уж заменил.
Где?

V>>Это маркетинг.

·>Маркетинг чего? Линус проплатил Майкрософту?!
Майкрософт продаёт свои поделия комьюнити на хайпе.

V>>·>Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.

V>>разве github не отказались от annex в пользу lfs?
·>Ах, ну раз lfs — это всё менят!
Т.е. твоё вангование про 10-15 лет это очередной заверон?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[33]: факапы на работе
От: · Великобритания  
Дата: 14.04.17 20:15
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>На той, что работу легко как раз похерить локально.

V>·>Так какой сервер-то? Counter Strike Server подойдёт?
V>Удалённый. Но ты продолжай ёрничать.
Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?

V>>>Он может всё что угодно иметь, каким образом статистика собирается то?

V>·>Если факты тебе не нравятся — тем хуже для фактов...
V>Какие факты, пока что одни интерпретации.
Факт — интерес к гиту значительно превышает интерес к другим системам контроля версий. У тебя есть другие факты?

V>·>Ок, приведи другие данные, котоые собраны более удобным для тебя способом.

V>Ты издеваешься или действительно не понимаешь что их просто не собрать?
Точно, вот Гугл собрал, но он собрал, очевидно, неверно, т.к. результаты получились не соответсвующие твоим фантазиям.

V>>>sourceforge опенсоурс.

V>·>Большое число проектов с sourceforge переехали в github.
V>Видел там и там.
Например?

V>>>·>Это, конечно, мой частный случай, но я лично наблюдал в двух крупных банках переезд ClearCase -> git (и даже принимал в этом участие) и svn -> git.

V>>>А я не наблюдал, дальше что?
V>·>А ты наблюдал переезды обратно?
V>Оупенсоурс в прайват? И как её можно наблюдать?
Переезд с гита на какую-то другую vcs.

V>>>Что он там замещает то?

V>·>Существующие vcs.
V>Но они живее всех живых.
Ага, просто они так пахнут.

V>>>Как, к примеру, гит заменит ревизии в свн?

V>·>git describe, build numbers, etc.
V>https://pukkaone.github.io/2010/12/19/build-number-git-repository.html
V>Куча каких то левых операций сделать чтобы только билд номер посмотреть? В свн это вообще из каропки и ничего не надо делать. Даже теги не надо ставить.
Это не единственный способ. Зависит от того что именно ты хочешь с этим номером делать и на кой он вообще нужен. Например, "git rev-list --count master" будет выдавать то, для чего обычно номер ревизии svn может быть использован в билдах.

V>>>Или простоту использования последнего?

V>·>Давно уж заменил.
V>Где?
Везде, самая явная простота — работа с бранчами.

V>>>Это маркетинг.

V>·>Маркетинг чего? Линус проплатил Майкрософту?!
V>Майкрософт продаёт свои поделия комьюнити на хайпе.
И ты правда ожидаешь, что хайп пройдёт и все опять с радостью полезут на sourcesafe?

V>>>·>Геймдев обычно особенный, там очень много крупных бинарников, что не очень хорошо ложится в git из коробки. Но со всякими git annex, et al вангую лет 10-15 на заметное изменение ситуации в пользу git и в этой области.

V>>>разве github не отказались от annex в пользу lfs?
V>·>Ах, ну раз lfs — это всё менят!
V>Т.е. твоё вангование про 10-15 лет это очередной заверон?
Ты читать не умеешь? Или не знаешь что такое "et al"?
Я вангую что перелезут на git со всяких префорсов. Но какую именно нашлёпку выберут для крупных бираников — annex, lfs, bigfiles, ... etc — я точно не знаю.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[34]: факапы на работе
От: Vain Россия google.ru
Дата: 14.04.17 23:05
Оценка:
Здравствуйте, ·, Вы писали:

V>>Удалённый. Но ты продолжай ёрничать.

·>Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?
у любого vcs есть ремоут сервер, что ты придуриваешься?

V>>Какие факты, пока что одни интерпретации.

·>Факт — интерес к гиту значительно превышает интерес к другим системам контроля версий. У тебя есть другие факты?
Только интерес? И это всё?

V>>·>Ок, приведи другие данные, котоые собраны более удобным для тебя способом.

V>>Ты издеваешься или действительно не понимаешь что их просто не собрать?
·>Точно, вот Гугл собрал, но он собрал, очевидно, неверно, т.к. результаты получились не соответсвующие твоим фантазиям.
Гугл собрал из открытых источников а не закрытых.

V>>·>Большое число проектов с sourceforge переехали в github.

V>>Видел там и там.
·>Например?
https://svn.boost.org/trac/boost/
https://github.com/boostorg
https://sourceforge.net/p/nsis/code/HEAD/tree/
https://github.com/kichik/nsis

V>>·>А ты наблюдал переезды обратно?

V>>Оупенсоурс в прайват? И как её можно наблюдать?
·>Переезд с гита на какую-то другую vcs.
Скорее попробуют гит, а потом вернуться.

V>>Но они живее всех живых.

·>Ага, просто они так пахнут.
А с чего ты взял что ощущаешь не свой запах?

V>>https://pukkaone.github.io/2010/12/19/build-number-git-repository.html

V>>Куча каких то левых операций сделать чтобы только билд номер посмотреть? В свн это вообще из каропки и ничего не надо делать. Даже теги не надо ставить.
·>Это не единственный способ. Зависит от того что именно ты хочешь с этим номером делать и на кой он вообще нужен. Например, "git rev-list --count master" будет выдавать то, для чего обычно номер ревизии svn может быть использован в билдах.
Лучше уж нафик нафик этот лесапет.

V>>Майкрософт продаёт свои поделия комьюнити на хайпе.

·>И ты правда ожидаешь, что хайп пройдёт и все опять с радостью полезут на sourcesafe?
Зачем, останутся каждый на своих vcs гораздо более привычных и простых.

·>Ты читать не умеешь? Или не знаешь что такое "et al"?

·>Я вангую что перелезут на git со всяких префорсов.
А что, у гита есть, к примеру, такая простая фича как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Отредактировано 14.04.2017 23:07 Vain . Предыдущая версия .
Re[35]: факапы на работе
От: landerhigh Пират  
Дата: 14.04.17 23:08
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?

V>у любого античного vcs есть ремоут сервер, что ты придуриваешься?

Исправил. гиту оно необязательно.

V>·>Я вангую что перелезут на git со всяких префорсов.

V>А что, у гита есть, к примеру, такой костыль как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.

Исправил снова. Не благодари.
Есть, но пользоваться им смысла нет никакого. Бранчи стоят дешево и работать с ними не в пример удобнее.
www.blinnov.com
Re[36]: факапы на работе
От: Vain Россия google.ru
Дата: 14.04.17 23:16
Оценка:
Здравствуйте, landerhigh, Вы писали:

V>>у любого античного vcs есть ремоут сервер, что ты придуриваешься?

L>Исправил. гиту оно необязательно.
Доооо. В общий репозиторий теперь не нужно заливать.

V>>·>Я вангую что перелезут на git со всяких префорсов.

V>>А что, у гита есть, к примеру, такой костыль как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.
L>Исправил снова. Не благодари.
Недождёшься.

L>Есть, но пользоваться им смысла нет никакого. Бранчи стоят дешево и работать с ними не в пример удобнее.

Щито? Я не хочу никаких бранчей, я хочу "положить в ящик" и пойти домой. Бранчи не могут быть дешевле этого.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[29]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 15.04.17 00:31
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.

V>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe. EA — perforce. Достаточно крупные компании для тебя?

Я лично имел дело с синхронизацией Perforce в EA между двумя удаленными командами. Одно неверное движение и репозиторий "замер" на 2 часа. Это уже сам по себе было настолько узкое место, что можно отнести к факап как есть.

Если еще не перешли на git, то так им и надо в рукотворном аду
Re[35]: факапы на работе
От: · Великобритания  
Дата: 15.04.17 09:32
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>Блин, хватит изворачиваться! Так скажи уж толком-то! Какой сервер-то? Какой он сервис предоставляет?

V>у любого vcs есть ремоут сервер, что ты придуриваешься?
У git нет сервера, если бы ты читал хотя бы то, что я тебе пишу, то давно бы понял что заблуждаешься. Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.
Но в обсуждаемом тут сценарии "бэкап поломаных промежуточных изменений" сервер не нужен, можно самому создать ещё один репо и использовать его в личных целях.

V>>>Какие факты, пока что одни интерпретации.

V>·>Факт — интерес к гиту значительно превышает интерес к другим системам контроля версий. У тебя есть другие факты?
V>Только интерес? И это всё?
У тебя опять проблема с пониманием.

V>>>Ты издеваешься или действительно не понимаешь что их просто не собрать?

V>·>Точно, вот Гугл собрал, но он собрал, очевидно, неверно, т.к. результаты получились не соответсвующие твоим фантазиям.
V>Гугл собрал из открытых источников а не закрытых.
Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.

V>>>·>Большое число проектов с sourceforge переехали в github.

V>>>Видел там и там.
V>·>Например?
V>https://svn.boost.org/trac/boost/
V>https://github.com/boostorg
V>https://sourceforge.net/p/nsis/code/HEAD/tree/
V>https://github.com/kichik/nsis
А ты сам посмотрел эти ссылки?

Boost is moving from Subversion centralized version control to Git distributed modular version control.

Зачем ты мне доказываешь, что ты не прав? Я это и так знаю.

V>>>Оупенсоурс в прайват? И как её можно наблюдать?

V>·>Переезд с гита на какую-то другую vcs.
V>Скорее попробуют гит, а потом вернуться.
И ты это наблюдал? Или опять фантазии?
V>·>Это не единственный способ. Зависит от того что именно ты хочешь с этим номером делать и на кой он вообще нужен. Например, "git rev-list --count master" будет выдавать то, для чего обычно номер ревизии svn может быть использован в билдах.
V>Лучше уж нафик нафик этот лесапет.
Ну продолжай грызть свой кактус

V>·>И ты правда ожидаешь, что хайп пройдёт и все опять с радостью полезут на sourcesafe?

V>Зачем, останутся каждый на своих vcs гораздо более привычных и простых.
Не в этой вселенной.

V>·>Ты читать не умеешь? Или не знаешь что такое "et al"?

V>·>Я вангую что перелезут на git со всяких префорсов.
V>А что, у гита есть, к примеру, такая простая фича как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.
Конечно, всегда была. "git stash" называется, и если тебе интересно внутреннее устройство, то реализована с помощью тех же бранчей.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[30]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 09:46
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V>>·>Собственно, если у тебя есть возражения — подкрепи хоть какими-нибудь данными.

V>>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe. EA — perforce. Достаточно крупные компании для тебя?
V_>Я лично имел дело с синхронизацией Perforce в EA между двумя удаленными командами. Одно неверное движение и репозиторий "замер" на 2 часа. Это уже сам по себе было настолько узкое место, что можно отнести к факап как есть.
Я знаю что они использовали старый софт, не знаю как сейчас.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[36]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 10:08
Оценка:
Здравствуйте, ·, Вы писали:

V>>у любого vcs есть ремоут сервер, что ты придуриваешься?

·>У git нет сервера, если бы ты читал хотя бы то, что я тебе пишу, то давно бы понял что заблуждаешься.
Я ничего и не говорил про гит, я писал про то, что чтобы закоммитить что-то удалённо в общую репу — нужен сервер.

V>Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.

т.е. сервер всё-таки есть?

·>Но в обсуждаемом тут сценарии "бэкап поломаных промежуточных изменений" сервер не нужен, можно самому создать ещё один репо и использовать его в личных целях.

И потереть его, ага

V>>Только интерес? И это всё?

·>У тебя опять проблема с пониманием.
У тебя проблема с интерпретацией фактов. Вымысел выдаёшь за реальность.

V>>Гугл собрал из открытых источников а не закрытых.

·>Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.
Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?

·>А ты сам посмотрел эти ссылки?

·>

Boost is moving from Subversion centralized version control to Git distributed modular version control.

И? Как это опровергает что и там и там есть?

·>Зачем ты мне доказываешь, что ты не прав? Я это и так знаю.

Зачем ты опять в лужу сел?

V>>Лучше уж нафик нафик этот лесапет.

·>Ну продолжай грызть свой кактус
Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.

V>>Зачем, останутся каждый на своих vcs гораздо более привычных и простых.

·>Не в этой вселенной.
Не в твой вселенной.

V>>А что, у гита есть, к примеру, такая простая фича как шелвинг чтобы на него переходить? Даже свн её собирается ввести ибо поняли её полезность и эффективность.

·>Конечно, всегда была. "git stash" называется, и если тебе интересно внутреннее устройство, то реализована с помощью тех же бранчей.
https://git-scm.com/docs/git-stash
Что то по количеству команд и ключей ни разу не напоминает два простых действия: положить и взять.
Вот сравни:

git:
git stash list [<options>]
git stash show [<stash>]
git stash drop [-q|--quiet] [<stash>]
git stash ( pop | apply ) [--index] [-q|--quiet] [<stash>]
git stash branch <branchname> [<stash>]
git stash [save [-p|--patch] [-k|--[no-]keep-index] [-q|--quiet]
         [-u|--include-untracked] [-a|--all] [<message>]]
git stash clear
git stash create [<message>]
git stash store [-m|--message <message>] [-q|--quiet] <commit>


perforce:
p4 [g-opts] shelve [-p] [file ...]
p4 [g-opts] shelve [-a option] [-p] -i [-f | -r]
p4 [g-opts] shelve [-a option] [-p] -r -c change
p4 [g-opts] shelve [-a option] [-p] -c change [-f] [file ...]
p4 [g-opts] shelve -d -c change [-f] [file ...]
p4 [g-opts] unshelve -s shelvedchange [-f -n] [-c change] [-b branch | -S stream [-P stream]] [file ...]


2 команды у perforce и 9 у гита.
Что ты там про кактус говорил?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[37]: факапы на работе
От: · Великобритания  
Дата: 15.04.17 11:02
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>У git нет сервера, если бы ты читал хотя бы то, что я тебе пишу, то давно бы понял что заблуждаешься.

V>Я ничего и не говорил про гит, я писал про то, что чтобы закоммитить что-то удалённо в общую репу
Причём тут общая репа? Мы вроде о приватой рассуждали.

V> — нужен сервер.

Не "нужен сервер", а "может быть сервер". Линус одно время получал коммиты через емейл.

V>>Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.

V>т.е. сервер всё-таки есть?
Может есть, а может и нет. Опционально.

V>·>Но в обсуждаемом тут сценарии "бэкап поломаных промежуточных изменений" сервер не нужен, можно самому создать ещё один репо и использовать его в личных целях.

V>И потереть его, ага
Каким образом?

V>>>Гугл собрал из открытых источников а не закрытых.

V>·>Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.
V>Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?
Опять сервера какие-то... Отдаст что?

V>·>А ты сам посмотрел эти ссылки?

V>·>

Boost is moving from Subversion centralized version control to Git distributed modular version control.

V>И? Как это опровергает что и там и там есть?
Я не говорю, что опровергает, я говорю, что это доказывает мой тезис, что с великого и прекрасного svn все бегут на этот жуткий ужасный git; дохнет твой любимый svn.

V>>>Лучше уж нафик нафик этот лесапет.

V>·>Ну продолжай грызть свой кактус
V>Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.
Потому что git предоставляет возможности, а не диктует одно "единственно верное" решение.

V>Вот сравни:

V>2 команды у perforce и 9 у гита.
V>Что ты там про кактус говорил?
И что ты своим невежеством пытаешься доказать?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 12:22
Оценка:
Здравствуйте, ·, Вы писали:

V>>Я ничего и не говорил про гит, я писал про то, что чтобы закоммитить что-то удалённо в общую репу

·>Причём тут общая репа? Мы вроде о приватой рассуждали.
Я не в курсе про что ты там у себя в голове рассуждал, тема про потерять изменения и, как следствие, необходимость сохранить их куда-нить отдельно от локального компа, к примеру, на удалённый сервер.

V>> — нужен сервер.

·>Не "нужен сервер", а "может быть сервер".
Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.

·>Линус одно время получал коммиты через емейл.

Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло
Автор: ·
Дата: 10.04.17
. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.

V>>>Можно иметь как сервер так называемый repository​ manager, который позволяет организовать множество репов для разных проектов, раздать права доступа, интегрировать с системой автобилдов, ревью, етс. Например, github.

V>>т.е. сервер всё-таки есть?
·>Может есть, а может и нет. Опционально.
Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.

V>>·>Но в обсуждаемом тут сценарии "бэкап поломаных промежуточных изменений" сервер не нужен, можно самому создать ещё один репо и использовать его в личных целях.

V>>И потереть его, ага
·>Каким образом?
Похерить изменения локально можно любым удобным для тебя способом.

V>>·>Думаю из поисковых данных, что вообще-то закрытый источник, открытый только гуглу.

V>>Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?
·>Опять сервера какие-то... Отдаст что?
Статистика как собирается? Как гугл узнает про сервер если у него нет домена? А если внутри сети? А если VPN? Дальше объяснять?

V>>И? Как это опровергает что и там и там есть?

·>Я не говорю, что опровергает, я говорю, что это доказывает мой тезис, что с великого и прекрасного svn все бегут на этот жуткий ужасный git; дохнет твой любимый svn.
Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.

V>>Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.

·>Потому что git предоставляет возможности, а не диктует одно "единственно верное" решение.
Дооо. Эти возможности и до гита можно было сделать, половина что-то нафик не сдалась.

V>>Что ты там про кактус говорил?

·>И что ты своим невежеством пытаешься доказать?
Опять в лужу сел?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[31]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 15.04.17 15:33
Оценка:
Здравствуйте, Vain, Вы писали:

V_>>Я лично имел дело с синхронизацией Perforce в EA между двумя удаленными командами. Одно неверное движение и репозиторий "замер" на 2 часа. Это уже сам по себе было настолько узкое место, что можно отнести к факап как есть.

V>Я знаю что они использовали старый софт, не знаю как сейчас.

Использовали клиент чутьб старее. P4C вместо P4V ЕМНИП

А ситуация с узким местом была не из-за клиента.
Re[39]: факапы на работе
От: · Великобритания  
Дата: 15.04.17 15:39
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Я ничего и не говорил про гит, я писал про то, что чтобы закоммитить что-то удалённо в общую репу

V>·>Причём тут общая репа? Мы вроде о приватой рассуждали.
V>Я не в курсе про что ты там у себя в голове рассуждал, тема про потерять изменения и, как следствие, необходимость сохранить их куда-нить отдельно от локального компа, к примеру, на удалённый сервер.
_К примеру_ можно и на сервер, но это может быть любой доступный сервер — ssh, ftp, nfs, даже smtp. Или вообще без сервера, на соседний компьютер (network drive), на флешку, и т.п., это совсем не то же, что ты утверждаешь что "у любого vcs есть ремоут сервер".

V>>> — нужен сервер.

V>·>Не "нужен сервер", а "может быть сервер".
V>Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.
Он нужен если ты хочешь централизованный code review, авто-билды и прочее. Т.е. не для бэкапов.

V>·>Линус одно время получал коммиты через емейл.

V>Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло
Автор: ·
Дата: 10.04.17
. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.

А ты пробовал? Ничего сложного, мало чем отличается от работы с "централизованным" сервером. Ознакомься с "git send-mail"/"git am".

V>>>т.е. сервер всё-таки есть?

V>·>Может есть, а может и нет. Опционально.
V>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.
Не абсолютно и обходимо.

V>>>И потереть его, ага

V>·>Каким образом?
V>Похерить изменения локально можно любым удобным для тебя способом.
Например? И чем этот удобный способ будет принципиально отличаться от похеривания бэкапов?

V>>>Каким образом масса закрытых серверов по миру отдаст что-то гуглу, если гугел даже не знает где искать? Перебор всех ip и портов?

V>·>Опять сервера какие-то... Отдаст что?
V>Статистика как собирается?
По поисковым запросам и информации на форумах, блогах, статьях, етс.

V>>>И? Как это опровергает что и там и там есть?

V>·>Я не говорю, что опровергает, я говорю, что это доказывает мой тезис, что с великого и прекрасного svn все бегут на этот жуткий ужасный git; дохнет твой любимый svn.
V>Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.
А это что по-твоему: "Boost is moving from Subversion centralized version control to Git"?

V>>>Кактус грызут те, кому надо массу команд и ключей в гите помнить, а также порядок массы рюшечношашечных операций, чтобы ничего вдруг не поломать/потерять.

V>·>Потому что git предоставляет возможности, а не диктует одно "единственно верное" решение.
V>Дооо. Эти возможности и до гита можно было сделать, половина что-то нафик не сдалась.
Многим — сдалась, поэтому svn и помирает.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 17:49
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V_>А ситуация с узким местом была не из-за клиента.

А из-за чего? Причём тут перфорс тогда?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[33]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 15.04.17 18:06
Оценка:
Здравствуйте, Vain, Вы писали:

V>А из-за чего? Причём тут перфорс тогда?


Общий удаленный P4 сервер, 5 ткм между офисами (LA-Монреаль)

Много файлов. Заметная latency. P4 нужно постоянное соединение с сервером. Если кто-то ошибся и сделал checkout на большом каталоге (директории), то чтобы вернуть в "обратный зад" требовалось еще пару часов
Re[40]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 18:10
Оценка:
Здравствуйте, ·, Вы писали:

V>>Я не в курсе про что ты там у себя в голове рассуждал, тема про потерять изменения и, как следствие, необходимость сохранить их куда-нить отдельно от локального компа, к примеру, на удалённый сервер.

·>_К примеру_ можно и на сервер, но это может быть любой доступный сервер — ssh, ftp, nfs, даже smtp. Или вообще без сервера, на соседний компьютер (network drive), на флешку, и т.п., это совсем не то же, что ты утверждаешь что "у любого vcs есть ремоут сервер".
Это не тоже самое, ты не сможешь, к примеру, автоматически смержиться. А если бы был сервер, то всё тоже, только с сохранением в удалённом репозитории.

V>>Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.

·>Он нужен если ты хочешь централизованный code review, авто-билды и прочее. Т.е. не для бэкапов.
А коммитить и брать удалённо ты как собрался? Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.

V>>Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло
Автор: ·
Дата: 10.04.17
. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.

·>А ты пробовал? Ничего сложного, мало чем отличается от работы с "централизованным" сервером. Ознакомься с "git send-mail"/"git am".
Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?

V>>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.

·>Не абсолютно и обходимо.
Пример?

V>>Похерить изменения локально можно любым удобным для тебя способом.

·>Например? И чем этот удобный способ будет принципиально отличаться от похеривания бэкапов?
К примеру, что в удалённой они физически на другой машине или диске. Удалённый репозиторий гораздо сложнее похерить по собственной глупости чем локальный (если ты только не хочешь специально это сделать), это же очевидно. К примеру, в свне это вообще невозможно без прямого доступа к базе.

V>>Статистика как собирается?

·>По поисковым запросам и информации на форумах, блогах, статьях, етс.
Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?

V>>Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.

·>А это что по-твоему: "Boost is moving from Subversion centralized version control to Git"?
Чем это доказывает, к примеру, что они отказываются от svn?

V>>Дооо. Эти возможности и до гита можно было сделать, половина что-то нафик не сдалась.

·>Многим — сдалась, поэтому svn и помирает.
Ты мне напоминаешь сектантов Илона Маска.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[34]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 18:27
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V>>А из-за чего? Причём тут перфорс тогда?

V_>Общий удаленный P4 сервер, 5 ткм между офисами (LA-Монреаль)
V_>Много файлов. Заметная latency. P4 нужно постоянное соединение с сервером. Если кто-то ошибся и сделал checkout на большом каталоге (директории), то чтобы вернуть в "обратный зад" требовалось еще пару часов
Выделенное не понял. Человек специально скачал корень на несколько гигов, а потом возмущался что не то скачал? И качал по-новой? А переместить вручную поддиректорию куда надо и туда сделать синк не судьба была? Просто выбор правильной ветки лежит исключительно на пользователе, причём здесь перфорс?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[35]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 15.04.17 19:03
Оценка:
Здравствуйте, Vain, Вы писали:


V_>>Общий удаленный P4 сервер, 5 ткм между офисами (LA-Монреаль)

V_>>Много файлов. Заметная latency. P4 нужно постоянное соединение с сервером. Если кто-то ошибся и сделал checkout на большом каталоге (директории), то чтобы вернуть в "обратный зад" требовалось еще пару часов
V>Выделенное не понял. Человек специально скачал корень на несколько гигов, а потом возмущался что не то скачал? И качал по-новой? А переместить вручную поддиректорию куда надо и туда сделать синк не судьба была? Просто выбор правильной ветки лежит исключительно на пользователе, причём здесь перфорс?

Один нечаянно сделал checkout каталога по ошибке. А undo checkout — долго, если сервер далеко. N файлов * latency

Никто больше checkout внутри этого каталога сделать не может, пока checkout не будет отменен.

По моему, так, с поправкой на 2011 год. Терминологию точно не помню — вроде checkout. Это когда сообщаешь серверу, "сейчас буду редактировать этот файл/каталог". А сервер снимает его read only и можно редактировать
Я в 13-м все свои "домашние" репозитории перевел на git и больше не сталкивался (== успешно забыл). До этого использовал Perforce в т.ч. и для себя
Re[41]: факапы на работе
От: · Великобритания  
Дата: 15.04.17 19:21
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>_К примеру_ можно и на сервер, но это может быть любой доступный сервер — ssh, ftp, nfs, даже smtp. Или вообще без сервера, на соседний компьютер (network drive), на флешку, и т.п., это совсем не то же, что ты утверждаешь что "у любого vcs есть ремоут сервер".

V>Это не тоже самое, ты не сможешь, к примеру, автоматически смержиться. А если бы был сервер, то всё тоже, только с сохранением в удалённом репозитории.
В гите мерж _всегда_ происходит в локальном репо. Сервер-несервер вообще никак влиять на мержи не может.

V>>>Не может быть а нужен почти всегда, ибо центральное хранилище. Хватит уже сказки про эфемерную распределённость в вакууме рассказывать.

V>·>Он нужен если ты хочешь централизованный code review, авто-билды и прочее. Т.е. не для бэкапов.
V>А коммитить и брать удалённо ты как собрался?
В гите коммит _всегда_ происходит в локальном репо. Брать удалённо — так же, используя любой механизм обмена с ремотами.

V>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.

В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.

V>>>Ну можно ещё вручную мержить, но что-то тебе оно не удобно вышло
Автор: ·
Дата: 10.04.17
. А коммиты через мыло мержить это ни в раз удобно, ага, не говоря уже о том, что любой коммит это транзакция с кучей препятствий и откатов. Так и вижу замыленных юзеров от этого способа.

V>·>А ты пробовал? Ничего сложного, мало чем отличается от работы с "централизованным" сервером. Ознакомься с "git send-mail"/"git am".
V>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?
Точно так же как и с обычными ветками.
send-mail/am это лишь один из видов транспорта коммитов. А ещё есть "git bundle", ну и традиционный push/fetch.

V>>>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.

V>·>Не абсолютно и обходимо.
V>Пример?
Ну, например, разберись что такое такое fork в github.

V>>>Похерить изменения локально можно любым удобным для тебя способом.

V>·>Например? И чем этот удобный способ будет принципиально отличаться от похеривания бэкапов?
V>К примеру, что в удалённой они физически на другой машине или диске. Удалённый репозиторий гораздо сложнее похерить по собственной глупости чем локальный (если ты только не хочешь специально это сделать), это же очевидно. К примеру, в свне это вообще невозможно без прямого доступа к базе.
Так в чём отличия-то? Создавай приватный репо физически на другой машине, никто не запрещает, никакой специальный установленный админами "сервер git" не нужен. Например, если у тебя есть доступ к network drive, ssh куда-нибудь или тупо флешка — этого достаточно.

V>>>Статистика как собирается?

V>·>По поисковым запросам и информации на форумах, блогах, статьях, етс.
V> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?
Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.

V>>>Ничего подобного не наблюдаю. Ты выдаешь свои фантазии за действительность.

V>·>А это что по-твоему: "Boost is moving from Subversion centralized version control to Git"?
V>Чем это доказывает, к примеру, что они отказываются от svn?
А что по-твоему означает слово "moving"?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[36]: факапы на работе
От: Vain Россия google.ru
Дата: 15.04.17 23:45
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V>>Выделенное не понял. Человек специально скачал корень на несколько гигов, а потом возмущался что не то скачал? И качал по-новой? А переместить вручную поддиректорию куда надо и туда сделать синк не судьба была? Просто выбор правильной ветки лежит исключительно на пользователе, причём здесь перфорс?

V_>Один нечаянно сделал checkout каталога по ошибке. А undo checkout — долго, если сервер далеко. N файлов * latency
V_>Никто больше checkout внутри этого каталога сделать не может, пока checkout не будет отменен.
V_>По моему, так, с поправкой на 2011 год. Терминологию точно не помню — вроде checkout. Это когда сообщаешь серверу, "сейчас буду редактировать этот файл/каталог". А сервер снимает его read only и можно редактировать
V_>Я в 13-м все свои "домашние" репозитории перевел на git и больше не сталкивался (== успешно забыл). До этого использовал Perforce в т.ч. и для себя
Как это не может? Я сомневаюсь что у перфорса нельзя одновременно читать из базы, да ещё в 2011 году. Может, всё-таки, кто-то лок сделал? Тогда да, там включается эксклюзивный доступ.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[42]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 00:12
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>_К примеру_ можно и на сервер, но это может быть любой доступный сервер — ssh, ftp, nfs, даже smtp. Или вообще без сервера, на соседний компьютер (network drive), на флешку, и т.п., это совсем не то же, что ты утверждаешь что "у любого vcs есть ремоут сервер".

V>>Это не тоже самое, ты не сможешь, к примеру, автоматически смержиться. А если бы был сервер, то всё тоже, только с сохранением в удалённом репозитории.
·>В гите мерж _всегда_ происходит в локальном репо. Сервер-несервер вообще никак влиять на мержи не может.
Я про выделенное, оно автоматически мержить ничего не будет.

V>>А коммитить и брать удалённо ты как собрался?

·>В гите коммит _всегда_ происходит в локальном репо. Брать удалённо — так же, используя любой механизм обмена с ремотами.
Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.

V>>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.

·>В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.
Я почему это не должно быть надо?

V>>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?

·>Точно так же как и с обычными ветками.
С чего вдруг также, если мыло никакой транзакционностью не обладает?

V>>>>Когда народу больше становится, то абсолютно необходимо. А это как правило всегда.

V>>·>Не абсолютно и обходимо.
V>>Пример?
·>Ну, например, разберись что такое такое fork в github.
Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?

·>Так в чём отличия-то? Создавай приватный репо физически на другой машине, никто не запрещает, никакой специальный установленный админами "сервер git" не нужен. Например, если у тебя есть доступ к network drive, ssh куда-нибудь или тупо флешка — этого достаточно.

А чем оно лучше обычного бэкапа тогда? Точно также можно подключить и всю папку скопировать, история то локальных изменений не нужна.

V>> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?

·>Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.
Это вообще не статистика.

·>А что по-твоему означает слово "moving"?

Так где мувинг то? Как работал репозиторий, так и работает.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[37]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 16.04.17 00:28
Оценка:
Здравствуйте, Vain, Вы писали:

V>Как это не может? Я сомневаюсь что у перфорса нельзя одновременно читать из базы, да ещё в 2011 году. Может, всё-таки, кто-то лок сделал? Тогда да, там включается эксклюзивный доступ.


Читать может, работать — нtт

В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.
Re[43]: факапы на работе
От: · Великобритания  
Дата: 16.04.17 10:02
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Это не тоже самое, ты не сможешь, к примеру, автоматически смержиться. А если бы был сервер, то всё тоже, только с сохранением в удалённом репозитории.

V>·>В гите мерж _всегда_ происходит в локальном репо. Сервер-несервер вообще никак влиять на мержи не может.
V>Я про выделенное, оно автоматически мержить ничего не будет.
В гите мерж _всегда_ происходит в локальном репо, другие репы и есть ли они вообще, не важно какой к ним доступ — никакого влияния на процесс мержа не оказывают.

V>>>А коммитить и брать удалённо ты как собрался?

V>·>В гите коммит _всегда_ происходит в локальном репо. Брать удалённо — так же, используя любой механизм обмена с ремотами.
V>Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.
Так какой сервер-то?? Counter Strike? Ещё раз. Это децентрализованная система контроля версий.

V>>>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.

V>·>В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.
V>Я почему это не должно быть надо?
А почему это должно быть надо?

V>>>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?

V>·>Точно так же как и с обычными ветками.
V>С чего вдруг также, если мыло никакой транзакционностью не обладает?
С того. Перестань философствовать, возьми да и сам попробуй. Делов-то.

V>>>Пример?

V>·>Ну, например, разберись что такое такое fork в github.
V>Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?
Просто _разберись_ что такое такое fork в github. Подсказка: pull requests.

V>·>Так в чём отличия-то? Создавай приватный репо физически на другой машине, никто не запрещает, никакой специальный установленный админами "сервер git" не нужен. Например, если у тебя есть доступ к network drive, ssh куда-нибудь или тупо флешка — этого достаточно.

V>А чем оно лучше обычного бэкапа тогда? Точно также можно подключить и всю папку скопировать, история то локальных изменений не нужна.
Тем что это просто ещё один репо, с которым работаешь ровно так же как и с любым другим.

V>>> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?

V>·>Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.
V>Это вообще не статистика.
А что по-твоему такое статистика?!

V>·>А что по-твоему означает слово "moving"?

V>Так где мувинг то? Как работал репозиторий, так и работает.
Так английский ты тоже не знаешь? Ну там "present continuous"... ничего не говорит?
Короче, приведи перевод той цитаты, даже любопытно.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[38]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 10:40
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V_>В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.

Так там просто флажок read only убирается, не? Я помню вручную его убирал и редактировал.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[38]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 12:01
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V>>Как это не может? Я сомневаюсь что у перфорса нельзя одновременно читать из базы, да ещё в 2011 году. Может, всё-таки, кто-то лок сделал? Тогда да, там включается эксклюзивный доступ.

V_>Читать может, работать — нtт
V_>В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.
Что-то я не понял про что ты говоришь, потому-что Perforce 2006.2 прекрасно даёт делать Open for Edit с разных компов (там красная и зелёная галки появляются, что говорит о том, что не только тобой файл начал редактироваться, что даёт возможность связаться с редактирующим файл и предварительно договориться и разграничить области редактирования до самого коммита (!) (где в гите вообще такая фишка есть???)). А при попытке закоммитить с коллизией — даёт ресолвить через мерж.
К тому же я не нашёл опции Check Out, есть опция Sync, есть опция Open for Edit/Delete, но именно Check Out — нету.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[44]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 12:43
Оценка:
Здравствуйте, ·, Вы писали:

V>>Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.

·>Так какой сервер-то?? Counter Strike? Ещё раз. Это децентрализованная система контроля версий.
Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?

V>>>>Централизация нужна вообще для всего, а не только для этого. Всё-равно есть сервер откуда все берут и куда все кладут, это неизбежно.

V>>·>В _Distributed_ Version Control System централизация не нужна по определению. Хотя, эту централизацию можно организовать в некой окресности, если вдруг станет надо.
V>>Я почему это не должно быть надо?
·>А почему это должно быть надо?
По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?

V>>>>Так как на счёт транзакций, сам будешь ресолвить и мержить? Кто коллизии будет разрешать, тоже git send-mail или человек?

V>>·>Точно так же как и с обычными ветками.
V>>С чего вдруг также, если мыло никакой транзакционностью не обладает?
·>С того. Перестань философствовать, возьми да и сам попробуй. Делов-то.
Зачем мне пробовать кактус?

V>>Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?

·>Просто _разберись_ что такое такое fork в github. Подсказка: pull requests.
И где там общая история?

V>>>> Это открытая инфа. Кто тебе в бложек про закрытый серв то напишет?

V>>·>Например, кто-то будет искать инфу о том как пользоваться git-ом, неважно — закрытым сервом или у себя дома. Или кто-то напишет в бложике, что у них в BigCompany Ltd переезжают на другую vcs.
V>>Это вообще не статистика.
·>А что по-твоему такое статистика?!
Ты читай внимательно что там измеряли, а измеряли там количество запросов по ключевым словам, т.е. в попугаях в вакууме, что ни разу не говорит о количестве серверов и статистике использования. Если народ не понимает как git использовать, он будет генерить массу запросов в гугл, что ни разу ни показатель хорошесть git, а скорее наоборот.
А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
Вот, к примеру, статистика по Preforce Helix (крутить вниз к цифрам): https://www.perforce.com/helix

Users: 36k
Transactions/day: 47M
Megabytes: 36M


V>>·>А что по-твоему означает слово "moving"?

V>>Так где мувинг то? Как работал репозиторий, так и работает.
·>Так английский ты тоже не знаешь? Ну там "present continuous"... ничего не говорит?
·>Короче, приведи перевод той цитаты, даже любопытно.
Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[39]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 16.04.17 15:15
Оценка:
Здравствуйте, Vain, Вы писали:
V_>>В каталоге тысячи artist assets (картинки, модели и т.п., в проекте несколько сотен тысяч файлов). На всем этом работают различные тулзы и они не дадут правильно работать с файлами (открыть на редактирование), которые уже checkout кто-то другой.
V>Что-то я не понял про что ты говоришь, потому-что Perforce 2006.2 прекрасно даёт делать Open for Edit с разных компов (там красная и зелёная галки появляются, что говорит о том, что не только тобой файл начал редактироваться, что даёт возможность связаться с редактирующим файл и предварительно договориться и разграничить области редактирования до самого коммита (!) (где в гите вообще такая фишка есть???)). А при попытке закоммитить с коллизией — даёт ресолвить через мерж.
V>К тому же я не нашёл опции Check Out, есть опция Sync, есть опция Open for Edit/Delete, но именно Check Out — нету.

Я не помню точно какие опции и как. Ибо забросил в пользу git. Но проблема была и IT отдел ничего не могла сделать.

Естественно, если было бы так просто то поставили бы опцию. Но шансы, что проблема в опции а не концептуальная, исчезающе мала.

Потом добавили какой-то местный кэширующий прокси, стало немного быстрее но проблема не была решена.
Re[40]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 15:28
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V_>Я не помню точно какие опции и как. Ибо забросил в пользу git. Но проблема была и IT отдел ничего не могла сделать.

V_>Естественно, если было бы так просто то поставили бы опцию. Но шансы, что проблема в опции а не концептуальная, исчезающе мала.
V_>Потом добавили какой-то местный кэширующий прокси, стало немного быстрее но проблема не была решена.
А с чего ты тогда взял что Perforce виноват а не какой-нить раутер между точками? Перфорс используют туча народу и такая проблема бы сразу была заметна всем.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[45]: факапы на работе
От: · Великобритания  
Дата: 16.04.17 15:40
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Это и есть коммит/апдейт с сервером, просто называется по-другому. Но сервер всё-равно надо держать, ибо все с ним будут обмениваться в любое время.

V>·>Так какой сервер-то?? Counter Strike? Ещё раз. Это децентрализованная система контроля версий.
V>Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?
Это общее место — локальный репо.

V>>>Я почему это не должно быть надо?

V>·>А почему это должно быть надо?
V>По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?
Да. Или он сам возьмёт у тебя, если ты расшаришь доступ к своему репо.

V>>>С чего вдруг также, если мыло никакой транзакционностью не обладает?

V>·>С того. Перестань философствовать, возьми да и сам попробуй. Делов-то.
V>Зачем мне пробовать кактус?
Чтобы хоть немного просветиться и не говорить чушь

V>>>Это ничуть не пример, это тоже самое что я отдельно скопирую репу свн в отдельный каталог и буду работать с ней независимо как и с исходной. Где пример с большим количеством народу и одной историей на всех?

V>·>Просто _разберись_ что такое такое fork в github. Подсказка: pull requests.
V>И где там общая история?
В грАфе истории

V>·>А что по-твоему такое статистика?!

V>Ты читай внимательно что там измеряли, а измеряли там количество запросов по ключевым словам, т.е. в попугаях в вакууме, что ни разу не говорит о количестве серверов и статистике использования. Если народ не понимает как git использовать, он будет генерить массу запросов в гугл, что ни разу ни показатель хорошесть git, а скорее наоборот.
V>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.
V>Вот, к примеру, статистика по Preforce Helix (крутить вниз к цифрам): https://www.perforce.com/helix
V>

V>Users: 36k
V>Transactions/day: 47M
V>Megabytes: 36M

"Complete ecosystem for Git-based development"... ах, вот оно как.

V>>>Так где мувинг то? Как работал репозиторий, так и работает.

V>·>Так английский ты тоже не знаешь? Ну там "present continuous"... ничего не говорит?
V>·>Короче, приведи перевод той цитаты, даже любопытно.
V>Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.
Да, как legacy. А что делать-то? Вот постепенно и переезжают.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[41]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 16.04.17 16:18
Оценка:
Здравствуйте, Vain, Вы писали:

V>А с чего ты тогда взял что Perforce виноват а не какой-нить раутер между точками? Перфорс используют туча народу и такая проблема бы сразу была заметна всем.


Потому что если бы проблема была в раутерах, то ее бы решили. Не

Туча народа использует P4 локально, где P4 и network latency не играют такой роли.

Иначе, при удаленных транзауциях делают pipelining. Вместо каждого мелкого запрос-ответ делается параллелизация запроса.


Но для меня все это имет крайне маловажное значение т.к.

1. Разобраться с git не составило проблем
2. Все мое уже давно перенесено в git вместе с историей
3. Проблемы EA и P4 остались далеко позади.
4. ... Если бы я был IT в EA: Проблемы и обсуждения такого рода должны решаться быстро и эффективно. Эффективный и быстрый поиск (полминуты для меня):



Первая ссылка,

Jul 15, 2014

. Что согласуется с наблюдениями 2011 г. И задает направление поиска.

Для тех кому еще это важно.
Re[46]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 18:03
Оценка:
Здравствуйте, ·, Вы писали:

V>>Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?

·>Это общее место — локальный репо.
Твой дом это общее место?

V>>По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?

·>Да. Или он сам возьмёт у тебя, если ты расшаришь доступ к своему репо.
Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.

V>>Зачем мне пробовать кактус?

·>Чтобы хоть немного просветиться и не говорить чушь
Чушь это расшаривать что-то кому-то.

V>>И где там общая история?

·>В грАфе истории
А зачем ты врёшь? Там 2 разные истории.

·>"Complete ecosystem for Git-based development"... ах, вот оно как.

Ну да, на базе их движка

V>>Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.

·>Да, как legacy. А что делать-то? Вот постепенно и переезжают.
А вот и ныне там (С)
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[42]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 18:17
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V>>А с чего ты тогда взял что Perforce виноват а не какой-нить раутер между точками? Перфорс используют туча народу и такая проблема бы сразу была заметна всем.

V_>Потому что если бы проблема была в раутерах, то ее бы решили. Не
V_>Туча народа использует P4 локально, где P4 и network latency не играют такой роли.
В EA которая разбросана по шарику как раз удалённо качают гигабайты.

V_>

V_>Первая ссылка,

Jul 15, 2014

. Что согласуется с наблюдениями 2011 г. И задает направление поиска.

ALAMEDA, Calif. (July 15, 2014) Perforce Software today announced a new federated architecture for the company’s version management engine, P4D, significantly reducing workflow latency across the development pipeline. Remote services, or Edge services, allow organizations to deploy full-scale versioning services closer to distributed teams to provide LAN-speed access to their source code, art files, documents and other assets they version in Perforce.

Так они что-то вроде прокси-кластера сделали, чтобы уменьшить общую нагрузку на центральный репозиторий. Я думаю в этом случае ни гит, ни свн уж подавно не способны справиться с такой нагрузкой, если уж кластер понадобился.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[47]: факапы на работе
От: · Великобритания  
Дата: 16.04.17 18:44
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Ещё раз, общее место для коммита/апдейта необходимо всегда, где там децентрализация, если УЖЕ требуется общая часть-центр для обмена? Пчёлы против мёда?

V>·>Это общее место — локальный репо.
V>Твой дом это общее место?
Нет.

V>>>По новому кругу идём. Как ты случайному челу передашь свои изменения, будешь его сам искать и предлагать свои изменения, или передашь в общий/центральный репозиторий, где он сам возьмёт?

V>·>Да. Или он сам возьмёт у тебя, если ты расшаришь доступ к своему репо.
V>Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.
Как минимум таких общих мест может быть несколько.

V>>>Зачем мне пробовать кактус?

V>·>Чтобы хоть немного просветиться и не говорить чушь
V>Чушь это расшаривать что-то кому-то.
Залить в общее место это тоже расшарить.

V>>>И где там общая история?

V>·>В грАфе истории
V>А зачем ты врёшь? Там 2 разные истории.
Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки). При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.

V>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.

Кстати, поинтересуйся размером одного только домена github.com, тут немного есть. На сегодняшний день он крупнейший в мире хостер исходников. А если сюда прибавить github enterprise и кучу других репо-менеджеров...

V>·>"Complete ecosystem for Git-based development"... ах, вот оно как.

V>Ну да, на базе их движка
Движка чего?

V>>>Причем здесь перевод? Когда есть факт текущего использования? Не говори гоп пока не перепрыгнешь.

V>·>Да, как legacy. А что делать-то? Вот постепенно и переезжают.
V>А вот и ныне там (С)
Проект масштаба boost в состоянии "in moving" запросто может быть несколько лет.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[48]: факапы на работе
От: Vain Россия google.ru
Дата: 16.04.17 21:54
Оценка:
Здравствуйте, ·, Вы писали:

V>>Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.

·>Как минимум таких общих мест может быть несколько.
Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.

V>>Чушь это расшаривать что-то кому-то.

·>Залить в общее место это тоже расшарить.
Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории. Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

V>>>>И где там общая история?

V>>·>В грАфе истории
V>>А зачем ты врёшь? Там 2 разные истории.
·>Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки).
Где ветки если корня нет? О чём ты говоришь?

·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.

Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.

V>>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.

·>Кстати, поинтересуйся размером одного только домена github.com, тут немного есть. На сегодняшний день он крупнейший в мире хостер исходников. А если сюда прибавить github enterprise и кучу других репо-менеджеров...
Ну так ты сравни с другими хостерами, которые не только гит предлагают.
Кстати, на гитхабе куча всякого шлака хостится потому-что бесплатно, типа этого: https://github.com/WhiteHouse
Отсюда и завышенная статистика.

V>>·>"Complete ecosystem for Git-based development"... ах, вот оно как.

V>>Ну да, на базе их движка
·>Движка чего?
vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы

V>>·>Да, как legacy. А что делать-то? Вот постепенно и переезжают.

V>>А вот и ныне там (С)
·>Проект масштаба boost в состоянии "in moving" запросто может быть несколько лет.
А в чем проблема? Там около 150 библиотек, все сгруппировано по папкам, бери да перености. К тому же есть готовые инструменты для переноса: https://help.github.com/articles/source-code-migration-tools/
Ты думаешь они за год не могли перенести весь буст? Не верю (C).
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[49]: факапы на работе
От: · Великобритания  
Дата: 16.04.17 23:56
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Я не собираюсь никому ничего расшаривать, это бред, есть общее место — туда и заливай.

V>·>Как минимум таких общих мест может быть несколько.
V>Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.
Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.

V>>>Чушь это расшаривать что-то кому-то.

V>·>Залить в общее место это тоже расшарить.
V>Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории.
Ну наконец-то дошло! Вот видишь — можно как оказалось заводить свои приватные локально-игрушечные репозитории для своих личных целей без всяких админов/ревьюверов.

V>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.

V>>>·>В грАфе истории

V>>>А зачем ты врёшь? Там 2 разные истории.
V>·>Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки).
V>Где ветки если корня нет? О чём ты говоришь?
Корень есть, конечно, форк/клон же делается от какого-то существующего репо, как правило.

V>·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.

V>Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.
Нет конечно, копий нет. История нелинейная. См. DAG. Просто git умеет мержить, в отличие от примитивных систем контроля версий типа svn.

V>>>А статистикой будет, к примеру, количество скачиваний+установок[+удалений] или количество активных репозиториев на разных опенспейс доменах.

V>·>Кстати, поинтересуйся размером одного только домена github.com, тут немного есть. На сегодняшний день он крупнейший в мире хостер исходников. А если сюда прибавить github enterprise и кучу других репо-менеджеров...
V>Ну так ты сравни с другими хостерами, которые не только гит предлагают.
С какими? Я же говорю, github — крупнейший в мире.

V>Кстати, на гитхабе куча всякого шлака хостится потому-что бесплатно, типа этого: https://github.com/WhiteHouse

V>Отсюда и завышенная статистика.
Допустим и шлак и что?.. Типа шлак хостить легче?

V>>>·>"Complete ecosystem for Git-based development"... ах, вот оно как.

V>>>Ну да, на базе их движка
V>·>Движка чего?
V>vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы
helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.

V>>>А вот и ныне там (С)

V>·>Проект масштаба boost в состоянии "in moving" запросто может быть несколько лет.
V>А в чем проблема? Там около 150 библиотек, все сгруппировано по папкам, бери да перености. К тому же есть готовые инструменты для переноса: https://help.github.com/articles/source-code-migration-tools/
V>Ты думаешь они за год не могли перенести весь буст? Не верю (C).
Как я понял, они не просто переносят, но и разделяют один огромный мега-проект на множество независимых библиотек. А вообще говоря, как я вижу разработка ведётся в основном в git, если ты посмотришь странички how to contribute, то там описывается именно git:

Attach a diff to Boost developers list message explaining the patch. Easy to do, but least effective.
Attach a diff to a patch ticket. Less likely to get lost in the shuffle than a mailing list attachment, but many developers prefer to get pull requests (see below).

но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[50]: факапы на работе
От: Vain Россия google.ru
Дата: 17.04.17 02:08
Оценка:
Здравствуйте, ·, Вы писали:

V>>Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.

·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.


V>>·>Залить в общее место это тоже расшарить.

V>>Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории.
·>Ну наконец-то дошло! Вот видишь — можно как оказалось заводить свои приватные локально-игрушечные репозитории для своих личных целей без всяких админов/ревьюверов.
Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.

V>>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

·>И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.
Какие к примеру?

V>>·>Я не вру, просто ты не хочешь разобраться. История одна, если юзеры делают коммиты — то история разветвляется (т.е. возникают ветки).

V>>Где ветки если корня нет? О чём ты говоришь?
·>Корень есть, конечно, форк/клон же делается от какого-то существующего репо, как правило.
Его нету, потому-что две разные базы, каждая со своей историей.

V>>·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.

V>>Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.
·>Нет конечно, копий нет. История нелинейная. См. DAG. Просто git умеет мержить, в отличие от примитивных систем контроля версий типа svn.
Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.

V>>Отсюда и завышенная статистика.

·>Допустим и шлак и что?.. Типа шлак хостить легче?
типа бесплатно можно и шлак.

V>>·>Движка чего?

V>>vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы
·>helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.
Это не компонента, это переходник туда обратно, чтобы перетаскивать юзеров
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[43]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 17.04.17 03:59
Оценка:
Здравствуйте, Vain, Вы писали:


V>ALAMEDA, Calif. (July 15, 2014) Perforce Software today announced a new federated architecture for the company’s version management engine, P4D, significantly reducing workflow latency across the development pipeline. Remote services, or Edge services, allow organizations to deploy full-scale versioning services closer to distributed teams to provide LAN-speed access to their source code, art files, documents and other assets they version in Perforce.

V>[/q]
V>Так они что-то вроде прокси-кластера сделали, чтобы уменьшить общую нагрузку на центральный репозиторий. Я думаю в этом случае ни гит, ни свн уж подавно не способны справиться с такой нагрузкой, если уж кластер понадобился.

Нет, не по этому

git работает с сервером в момент clone, push и pull. И то только если нужно работать именно с этим remote, что для полноценной работы вовсе не обязательно.

Perforce работает с сервером покаждому чиху. Постоянно.
Чтобы обойти эту концептуальную проблему Perforce и понадобился кластер. То что я имел честь наблюдать на практике.
Re[44]: факапы на работе
От: Vain Россия google.ru
Дата: 17.04.17 06:51
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V_>Perforce работает с сервером покаждому чиху. Постоянно.

А почему Perforce не должен работать постоянно, это же не только vcs, а система постоянного мониторинга файлов, changelist'ов, веток и других пользователей? Я, к примеру, могу видеть что другие пользователи делают просто нажав F5 на депозитории или группе файлов.

V_>Чтобы обойти эту концептуальную проблему Perforce и понадобился кластер. То что я имел честь наблюдать на практике.

На практике ты имел честь наблюдать скорее перегруз от миллиона запросов в секунду.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re: факапы на работе
От: Iron Monkey  
Дата: 17.04.17 07:39
Оценка:
HC>Тут у нас программист один случайно похерил результаты своей недели работы. И его заставляют выходить на работу в выходные и за свой счет это все восстанавливать. Меня что-то от этого прям корежит. Как считаете это норм?

Неделя, это, конечно, перебор
У меня такое было в меньших масштабах — уже в конце рабочего дня, перед коммитом, что-то как-то не туда даванул в коммандере и похерил последние 4 часа своего труда. Сначала чуть в обморок не шарахнулся, потом оклемался и начал заново писать. Звонит шеф часа через два: "ты на работе до сих пор? да забей, потом доделаешь!". Вот так. Внимательней надо быть
А этот тип сам виноват отчасти — если контора не может организовать нормальный бэкап, организуй его себе сам. Или не работай там. И нечего тут потеряшку беспомощного строить
Re[51]: факапы на работе
От: · Великобритания  
Дата: 17.04.17 10:39
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Мне плевать сколько их, я хочу брать из одного и класть в одно. И таких как я — тьма.

V>·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.
V>
Ага, точно — тьма и мрак.

V>>>Кто про твоё общее место знает? Если вас в команде больше 10ка, остальным будет тупо плевать на твои локально-игрушечные репозитории.

V>·>Ну наконец-то дошло! Вот видишь — можно как оказалось заводить свои приватные локально-игрушечные репозитории для своих личных целей без всяких админов/ревьюверов.
V>Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.
Нет, не все.

V>>>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

V>·>И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.
V>Какие к примеру?
https://www.perforce.com/support/tutorial-video-library/video/distributed-versioning-tutorial

V>>>Где ветки если корня нет? О чём ты говоришь?

V>·>Корень есть, конечно, форк/клон же делается от какого-то существующего репо, как правило.
V>Его нету, потому-что две разные базы, каждая со своей историей.
Ты это так уверенно заявляешь. И ты хоть как-то это можешь подвердить?

V>>>·>При мержах — опять сливается. Если все всё смержат — у всех будет идентичная общая история всех коммитов от всех юзеров.

V>>>Это будут две разные истории, пусть даже в одной будет частично копия другой. Одна история должна всегда идти линейно.
V>·>Нет конечно, копий нет. История нелинейная. См. DAG. Просто git умеет мержить, в отличие от примитивных систем контроля версий типа svn.
V>Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.
Нет, если ты имеешь в виду "svn merge", то видимо ты доку не читал: "Apply the differences between two sources to a working copy path." Т.е. это банально наложение патча на wc.
Сравни с "git merge" докой: "Join two or more development histories together". Т.е. мерж как слияние истории. А то что делает svn это больше соответствует одному из сценариев "rebase": "Reapply commits on top of another base tip", т.е. наложение коммитов (патчей) поверх другой истории.
В svn вроде есть какой-то костыль в виде merge tracking info, но это мрак и тьма.

V>>>Отсюда и завышенная статистика.

V>·>Допустим и шлак и что?.. Типа шлак хостить легче?
V>типа бесплатно можно и шлак.
Этот шлак не особо и развивается, и нагрузку не создаёт. Но в github есть очень много популярных и активных проектов.
А вообще, посмотришь на любой internal repo какой-нибудь старой большой богатой организации — там шлака столько же.
И что ты хочешь доказать-то?

V>>>·>Движка чего?

V>>>vcs, perforce использует свою базу и показывает коммиты git'а как свои changelist'ы
V>·>helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.
V>Это не компонента, это переходник туда обратно, чтобы перетаскивать юзеров
Переходник откуда и куда? Я ничего не понял.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[45]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 17.04.17 13:34
Оценка:
Здравствуйте, Vain, Вы писали:

V>А почему Perforce не должен работать постоянно, это же не только vcs, а система постоянного мониторинга файлов, changelist'ов, веток и других пользователей? Я, к примеру, могу видеть что другие пользователи делают просто нажав F5 на депозитории или группе файлов.


Это и оборачивается в факап P4 при распределенной командной разработке что и требует вспомогательных костылей

V>На практике ты имел честь наблюдать скорее перегруз от миллиона запросов в секунду.


Ты не просто не понимаешь а еще пытаешся угадать

"Простой перегруз" это простое объяснение для людей не понимающих в распределенной обработке и архитектуре. Еще можно молотком постучать. Может, поможет. Ага.

Простой перегруз прекрасно лечится более быстрым серевером и/или широким каналом.

Но если в локальной сети все работает быстро а удаленно — нет, при достаточном канале, то здесь решить можно только переделкой продукта или его заменой. Ибо ограничено при неизменности продукта network latency, где значительный компонент это скорость света (сигнала по проводам).

Возвращаясь к исходному факапу P4, здесь все очевидно (для меня), понятно и дальнейшее обсуждение исчерпано ибо бессмысленно за неимением базы.
Отредактировано 17.04.2017 19:51 Vetal_ca . Предыдущая версия .
Re[52]: факапы на работе
От: Vain Россия google.ru
Дата: 17.04.17 19:49
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.

V>>
·>Ага, точно — тьма и мрак.
Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".

V>>Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.

·>Нет, не все.
свн и перфорс позволяют создать сервер локально.

V>>>>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

V>>·>И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.
V>>Какие к примеру?
·>https://www.perforce.com/support/tutorial-video-library/video/distributed-versioning-tutorial
Так там мастер сервер:

You can push and fetch content on all these servers with the protections you are accustomed to in the Helix master server.

По твоей идеалогии это нифига не распределённо, раз есть центральный сервер.

V>>Его нету, потому-что две разные базы, каждая со своей историей.

·>Ты это так уверенно заявляешь. И ты хоть как-то это можешь подвердить?
На разнах компах находятся, в каждом своя история. Чем не подтверждение?

V>>Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.

·>Нет, если ты имеешь в виду "svn merge", то видимо ты доку не читал: "Apply the differences between two sources to a working copy path." Т.е. это банально наложение патча на wc.
В свн есть свой панельный мержер, где можно руками мержить в случае коллизии.

·>Сравни с "git merge" докой: "Join two or more development histories together". Т.е. мерж как слияние истории. А то что делает svn это больше соответствует одному из сценариев "rebase": "Reapply commits on top of another base tip", т.е. наложение коммитов (патчей) поверх другой истории.

В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.

·>Этот шлак не особо и развивается, и нагрузку не создаёт. Но в github есть очень много популярных и активных проектов.

·>А вообще, посмотришь на любой internal repo какой-нибудь старой большой богатой организации — там шлака столько же.
·>И что ты хочешь доказать-то?
То, что больше пользуются бесплатно самим хостингом для хранения файла, а не самим гитом. Тут играет роль удобство сервиса, а не фичи гита, которые ты пытаешься продемонстрировать в доказательство популярности GitHub'а.

V>>·>helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.

V>>Это не компонента, это переходник туда обратно, чтобы перетаскивать юзеров
·>Переходник откуда и куда? Я ничего не понял.
Перетаскивать юзеров с гита на перфорс, это же очевидно.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[46]: факапы на работе
От: Vain Россия google.ru
Дата: 17.04.17 19:53
Оценка:
Здравствуйте, Vetal_ca, Вы писали:

V>>А почему Perforce не должен работать постоянно, это же не только vcs, а система постоянного мониторинга файлов, changelist'ов, веток и других пользователей? Я, к примеру, могу видеть что другие пользователи делают просто нажав F5 на депозитории или группе файлов.

V_>Это и оборачивается в факап P4 при распределенной командной разработке что и требует вспомогательных костылей
Ничего не понял, каких ещё костылей? Постоянное соединение с сервером не обязательно, если ты все уже скачал, оно требуется только для мониторинга активности других юзеров в сети. Это ни разу не костыль.

V>>На практике ты имел честь наблюдать скорее перегруз от миллиона запросов в секунду.

V_>Я прекарсно понимаю что происходит, тут очевидно ты за мной медленно догоняешь происходящее. Не нужно перекручивать.
V_>Возвращаясь к исходному факапу P4, здесь все очевидно, понятно и дальнейшее обсуждение исчерпано.
Больше похоже, что ты себе какое-то оправдание придумал и уверовал в него. А все остальные пользователи используют Perforce и не плюются.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[47]: факапы на работе
От: Vetal_ca Канада http://vetal.ca
Дата: 17.04.17 20:15
Оценка:
Здравствуйте, Vain, Вы писали:

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



V>Больше похоже, что ты себе какое-то оправдание придумал и уверовал в него. А все остальные пользователи используют Perforce и не плюются.


Это ты не понимаешь что такое network latency и делаешь выводы не догадываясь о сути проблемы.

Если пошли выводы "все остальные, общепринято, всегда" — уровень компетенции собеседника исчерпан.

Я привел пример проблемы с распределенной командой и удаленными офисами. Чтобы не было бесполезного монолога почитай, что такое Protocol pipelining

Пока же это бесполезная потеря времени
Re[53]: факапы на работе
От: · Великобритания  
Дата: 17.04.17 20:50
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>·>Да пожалуйста. Хочешь — клади в одно. Но если понадобится что-то иное — сделать бэкап, обменяться незаконченной работой с коллегой, переслать изменения на другой свой компьютер или виртуалку — и внезапно мест становится много.

V>>>
V>·>Ага, точно — тьма и мрак.
V>Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".
Да пожалуйста, гит не запрещает тебе иметь центральный сервер. Плохо, когда эта фича и первым делом и последним является, хочешь положить соседу в репу, а не можешь.

V>>>Ты и так это можешь делать, без всяких гитов. Все системы контроля это позволяют.

V>·>Нет, не все.
V>свн и перфорс позволяют создать сервер локально.
Как клон какого-то существующего репо? Да чтобы потом замержить новые изменения обратно?

V>>>>>Поэтому вся идеалогия распределённости просто разваливается как карточный домик.

V>>>·>И поэтому даже этот твой самый perforce внезапно стал распределённые фичи вводить.
V>>>Какие к примеру?
V>·>https://www.perforce.com/support/tutorial-video-library/video/distributed-versioning-tutorial
V>Так там мастер сервер:
V>

V>You can push and fetch content on all these servers with the protections you are accustomed to in the Helix master server.

V>По твоей идеалогии это нифига не распределённо, раз есть центральный сервер.
У тебя с логикой беда. Распределённо это когда есть возможность распределить, т.е. опциональность центрального сервера, а не запрет на наличие центрального сервера.

V>>>Его нету, потому-что две разные базы, каждая со своей историей.

V>·>Ты это так уверенно заявляешь. И ты хоть как-то это можешь подвердить?
V>На разнах компах находятся, в каждом своя история. Чем не подтверждение?
Ага, только эта история — идентична. "своя история" существует только до мержа.

V>>>Щито? Свн тоже умеет мержить, с добрым утром. Это на сегодняшний день вообще все системы контроля версий умеют.

V>·>Нет, если ты имеешь в виду "svn merge", то видимо ты доку не читал: "Apply the differences between two sources to a working copy path." Т.е. это банально наложение патча на wc.
V>В свн есть свой панельный мержер, где можно руками мержить в случае коллизии.
А в Киеве — дядька. Причём тут коллизии?

V>·>Сравни с "git merge" докой: "Join two or more development histories together". Т.е. мерж как слияние истории. А то что делает svn это больше соответствует одному из сценариев "rebase": "Reapply commits on top of another base tip", т.е. наложение коммитов (патчей) поверх другой истории.

V>В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.
Ты не мержишь, а просто делаешь дифф между двумя коммитами и накладываешь его на текующую wc и делаешь новый коммит, который никак логически не связан в _истории_ с первыми двумя. Кроме как корявый mergeinfo.

V>·>Этот шлак не особо и развивается, и нагрузку не создаёт. Но в github есть очень много популярных и активных проектов.

V>·>А вообще, посмотришь на любой internal repo какой-нибудь старой большой богатой организации — там шлака столько же.
V>·>И что ты хочешь доказать-то?
V>То, что больше пользуются бесплатно самим хостингом для хранения файла, а не самим гитом. Тут играет роль удобство сервиса, а не фичи гита, которые ты пытаешься продемонстрировать в доказательство популярности GitHub'а.
Ну а перфорс везде и всегда используется для хранения исключительно нетленных гениальных исходников. Забабахать туда пачку файлов ради "шоб было" типа нельзя...

V>>>·>helix это вообще-то интегрированная инфраструктура нескольких компонент типа TFS, а vcs компонента так же выбирается — либо p4, либо git.

V>>>Это не компонента, это переходник туда обратно, чтобы перетаскивать юзеров
V>·>Переходник откуда и куда? Я ничего не понял.
V>Перетаскивать юзеров с гита на перфорс, это же очевидно.
helix чтобы перетаскивать с git на p4? И много ты таких перетасканных наблюдал?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[54]: факапы на работе
От: Vain Россия google.ru
Дата: 17.04.17 22:51
Оценка:
Здравствуйте, ·, Вы писали:

V>>Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".

·>Да пожалуйста, гит не запрещает тебе иметь центральный сервер. Плохо, когда эта фича и первым делом и последним является, хочешь положить соседу в репу, а не можешь.
С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.

V>>свн и перфорс позволяют создать сервер локально.

·>Как клон какого-то существующего репо? Да чтобы потом замержить новые изменения обратно?
Мерж двух каталогов, эта тулзовина даже отношения к vcs не имеет.

V>>На разнах компах находятся, в каждом своя история. Чем не подтверждение?

·>Ага, только эта история — идентична. "своя история" существует только до мержа.
Ты же не всю историю мержишь, а только часть, какую-то ветку, следовательно, там никогда полной истории и не будет. Будут копии кусков одного в другом, это не полная история.

V>>В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.

·>Ты не мержишь, а просто делаешь дифф между двумя коммитами и накладываешь его на текующую wc и делаешь новый коммит, который никак логически не связан в _истории_ с первыми двумя. Кроме как корявый mergeinfo.
У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям, не понимаю причём здесь дифф, если он существует только для одного и того же файла.

V>>То, что больше пользуются бесплатно самим хостингом для хранения файла, а не самим гитом. Тут играет роль удобство сервиса, а не фичи гита, которые ты пытаешься продемонстрировать в доказательство популярности GitHub'а.

·>Ну а перфорс везде и всегда используется для хранения исключительно нетленных гениальных исходников. Забабахать туда пачку файлов ради "шоб было" типа нельзя...
Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?

V>>·>Переходник откуда и куда? Я ничего не понял.

V>>Перетаскивать юзеров с гита на перфорс, это же очевидно.
·>helix чтобы перетаскивать с git на p4? И много ты таких перетасканных наблюдал?
Это надо спросить у перфорса, сколько клиентов перешли на их сервис.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[55]: факапы на работе
От: · Великобритания  
Дата: 18.04.17 09:28
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Ага, пытаюсь тебе объяснить, что первым делом нужна фича положить/взять на/с сервер(а) а не положить соседу в репу. А ты "хочешь — клади в одно".

V>·>Да пожалуйста, гит не запрещает тебе иметь центральный сервер. Плохо, когда эта фича и первым делом и последним является, хочешь положить соседу в репу, а не можешь.
V>С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.
Ты не хочешь (как мне кажется лишь потому, что не умеешь), другие хотят.

V>>>свн и перфорс позволяют создать сервер локально.

V>·>Как клон какого-то существующего репо? Да чтобы потом замержить новые изменения обратно?
V>Мерж двух каталогов, эта тулзовина даже отношения к vcs не имеет.
А что имеет?
Собственно если эти два каталога — две немного разные версии исходников одного и того же проекта, то это прямая обязанность любой приличной vcs дать возможность их всяко сравнивать и мержить.

V>>>На разнах компах находятся, в каждом своя история. Чем не подтверждение?

V>·>Ага, только эта история — идентична. "своя история" существует только до мержа.
V>Ты же не всю историю мержишь, а только часть, какую-то ветку, следовательно, там никогда полной истории и не будет.
Не понимаю к чему ты это говоришь. Ну если тебе нужно замержить часть, то будет частично смерженная история. Если тебе нужно замержить всё, история будет полностью смерженной. Почему никогда?

V>Будут копии кусков одного в другом, это не полная история.

Копии будут в vcs которые мержить не умеют, типа svn.
Прежде чем заявлять очередную глупость, скажи, ты разобрался с history DAG?

V>>>В свн ты мержишь локально между коммитами, которые и формируют историю, т.е. в свн честная история.

V>·>Ты не мержишь, а просто делаешь дифф между двумя коммитами и накладываешь его на текующую wc и делаешь новый коммит, который никак логически не связан в _истории_ с первыми двумя. Кроме как корявый mergeinfo.
V>У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям,
Что такое "исходный файл"? И какая его взаимосвязь с "файлом из бранча"?

V>не понимаю причём здесь дифф,

выделил специально для тебя:

svn merge — Apply the differences between two sources to a working copy path.

(с) http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.merge.html

V>если он существует только для одного и того же файла.

Мерж в svn это получение разницы между изменениями сделанными в одном бранче и применение этой разницы к рабочей копии. Так?

V>>>То, что больше пользуются бесплатно самим хостингом для хранения файла, а не самим гитом. Тут играет роль удобство сервиса, а не фичи гита, которые ты пытаешься продемонстрировать в доказательство популярности GitHub'а.

V>·>Ну а перфорс везде и всегда используется для хранения исключительно нетленных гениальных исходников. Забабахать туда пачку файлов ради "шоб было" типа нельзя...
V>Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?
Платность-бесплатность тут не причём. github тоже не всегда бесплатный. Мало того, был вот бесплатный sourceforge на базе svn — почему он не крупнейший?

V>>>Перетаскивать юзеров с гита на перфорс, это же очевидно.

V>·>helix чтобы перетаскивать с git на p4? И много ты таких перетасканных наблюдал?
V>Это надо спросить у перфорса, сколько клиентов перешли на их сервис.
Спроси, посмеёмся.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Отредактировано 18.04.2017 9:35 · . Предыдущая версия .
Re[56]: факапы на работе
От: Vain Россия google.ru
Дата: 18.04.17 23:28
Оценка:
Здравствуйте, ·, Вы писали:

V>>С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.

·>Ты не хочешь (как мне кажется лишь потому, что не умеешь), другие хотят.
Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься. А вот уже в общий транк хочешь не хочешь, а мержить придётся.

V>>Мерж двух каталогов, эта тулзовина даже отношения к vcs не имеет.

·>А что имеет?
·>Собственно если эти два каталога — две немного разные версии исходников одного и того же проекта, то это прямая обязанность любой приличной vcs дать возможность их всяко сравнивать и мержить.
Не обязательно. В этом суть простоты vcs, которая позволяет использовать всем привычные вещи как, к примеру, голую файловую систему и любую тулзовину для мержа на ней.

V>>Ты же не всю историю мержишь, а только часть, какую-то ветку, следовательно, там никогда полной истории и не будет.

·>Не понимаю к чему ты это говоришь. Ну если тебе нужно замержить часть, то будет частично смерженная история. Если тебе нужно замержить всё, история будет полностью смерженной. Почему никогда?
Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории. Это больше напрягает, чем решает какие-то проблемы.

V>>Будут копии кусков одного в другом, это не полная история.

·>Копии будут в vcs которые мержить не умеют, типа svn.
Я пока одни глупости про свн от тебя слышу.

·>Прежде чем заявлять очередную глупость, скажи, ты разобрался с history DAG?

разберись сначала с простой системой типа свн.

V>>У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям,

·>Что такое "исходный файл"? И какая его взаимосвязь с "файлом из бранча"?
Такая что тебе общий файл нужен на выходе, а не их разница.

V>>не понимаю причём здесь дифф,

·>выделил специально для тебя:
·>

svn merge — Apply the differences between two sources to a working copy path.

(с) http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.merge.html

Ну да, это он делает для хранения истории изменений. А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

V>>если он существует только для одного и того же файла.

·>Мерж в svn это получение разницы между изменениями сделанными в одном бранче и применение этой разницы к рабочей копии. Так?
Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.

V>>Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?

·>Платность-бесплатность тут не причём. github тоже не всегда бесплатный. Мало того, был вот бесплатный sourceforge на базе svn — почему он не крупнейший?
У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным. У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.

V>>Это надо спросить у перфорса, сколько клиентов перешли на их сервис.

·>Спроси, посмеёмся.
Крупные компании просто ржут в голос.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[57]: факапы на работе
От: · Великобритания  
Дата: 19.04.17 09:29
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>С чего вдруг я должен хотеть, если я даже не знаю где этот сосед? В общем случае таких соседов дофигища и мне болт положить, что они там у себя в репозиториях нахреначили.

V>·>Ты не хочешь (как мне кажется лишь потому, что не умеешь), другие хотят.
V>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.
Это тебе так кажется потому что ты не умеешь. А популярность pull requests тебе ни на что не намекает?

V>А вот уже в общий транк хочешь не хочешь, а мержить придётся.

Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.

V>·>А что имеет?

V>·>Собственно если эти два каталога — две немного разные версии исходников одного и того же проекта, то это прямая обязанность любой приличной vcs дать возможность их всяко сравнивать и мержить.
V>Не обязательно. В этом суть простоты vcs, которая позволяет использовать всем привычные вещи как, к примеру, голую файловую систему и любую тулзовину для мержа на ней.
У тебя опять с логикой проблемы. "дать возможность" не означает, что возникает запрет на использование "привычних вещей". Как раз git позволяет на порядки проще взять голую файловую систему, превратить в репозиторий (git init), смержить с любым другим репозиторием (git fetch/merge), перекроить историю (graft/replace/filter-branch), потом обратно сделать голую файловую систему (rm -r .git) и т.д., и т.п. Svn-у такого и не снилось. Я даже натыкался на вопросы типа "как в svn сделать X" и ответы "импортните svn в git, сделайте X, экспортните git в svn".

V>>>Ты же не всю историю мержишь, а только часть, какую-то ветку, следовательно, там никогда полной истории и не будет.

V>·>Не понимаю к чему ты это говоришь. Ну если тебе нужно замержить часть, то будет частично смерженная история. Если тебе нужно замержить всё, история будет полностью смерженной. Почему никогда?
V>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.
Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.

V>Это больше напрягает, чем решает какие-то проблемы.

Ты, главное, не напрягайся.

V>>>Будут копии кусков одного в другом, это не полная история.

V>·>Копии будут в vcs которые мержить не умеют, типа svn.
V>Я пока одни глупости про свн от тебя слышу.
Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.

V>·>Прежде чем заявлять очередную глупость, скажи, ты разобрался с history DAG?

V>разберись сначала с простой системой типа свн.
Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?

V>>>У тебя есть исходный файл и, к примеру, файл из бранча, который ты как раз мержишь. Они физически по разным путям,

V>·>Что такое "исходный файл"? И какая его взаимосвязь с "файлом из бранча"?
V>Такая что тебе общий файл нужен на выходе, а не их разница.
А что по-твоему является результатом операции "apply the differences"?

V>>>не понимаю причём здесь дифф,

V>·>выделил специально для тебя:
V>·>

svn merge — Apply the differences between two sources to a working copy path.

(с) http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.merge.html

V>Ну да, это он делает для хранения истории изменений.
Что "это"?? Причём тут вообще хранение истории?

V>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

Перечисли плиз, _со ссылкой на доку svn_.

V>>>если он существует только для одного и того же файла.

V>·>Мерж в svn это получение разницы между изменениями сделанными в одном бранче и применение этой разницы к рабочей копии. Так?
В смысле ты считаешь это высказывание неверным?

V>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.

Это общие слова. А как конкретно это работает в svn?

V>>>Причем здесь перфорс, если речь про бесплатный хостер на базе версионирования?

V>·>Платность-бесплатность тут не причём. github тоже не всегда бесплатный. Мало того, был вот бесплатный sourceforge на базе svn — почему он не крупнейший?
V>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.
Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?

V>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.

Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[58]: факапы на работе
От: Vain Россия google.ru
Дата: 19.04.17 13:41
Оценка:
Здравствуйте, ·, Вы писали:

V>>Я вижу что другие тоже не хотят, потому-что это лишний геморрой с мержем чужого кода, никто этим не хочет заниматься.

·>Это тебе так кажется потому что ты не умеешь.
Ты путаешь не умею с не хочу.

·>А популярность pull requests тебе ни на что не намекает?

Что ещё за популярность? Звучит как популярность геев и садомазо.

V>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.

·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.

V>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.

·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.

V>>Я пока одни глупости про свн от тебя слышу.

·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
Ты хотя бы вдумывайся для кого она написана и что там написано.

V>>разберись сначала с простой системой типа свн.

·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
Да мне плевать, вот честно.

V>>Такая что тебе общий файл нужен на выходе, а не их разница.

·>А что по-твоему является результатом операции "apply the differences"?
Алгоритм не обязан apply differences делать, у него на входе целые файлы.

V>>Ну да, это он делает для хранения истории изменений.

·>Что "это"?? Причём тут вообще хранение истории?
Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.

V>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

·>Перечисли плиз, _со ссылкой на доку svn_.
С чего ты взял что в доке рассказано про внутренние алгоритмы свн?

V>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.

·>Это общие слова. А как конкретно это работает в svn?
Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.

V>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.

·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.

V>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.

·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой. В сорсфорже по-другому, там надо изначально самому архив создать и залить.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Отредактировано 19.04.2017 13:46 Vain . Предыдущая версия . Еще …
Отредактировано 19.04.2017 13:43 Vain . Предыдущая версия .
Re[59]: факапы на работе
От: · Великобритания  
Дата: 19.04.17 14:29
Оценка:
Здравствуйте, Vain, Вы писали:

V>·>Это тебе так кажется потому что ты не умеешь.

V>Ты путаешь не умею с не хочу.
Ну потому и "не хочешь", т.к. не умеешь.

V>·>А популярность pull requests тебе ни на что не намекает?

V>Что ещё за популярность? Звучит как популярность геев и садомазо.
Веский аргумент.

V>>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.

V>·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.


V>>>Я хочу всегда полную и действительную историю всего репозитория, а не куски разбросанные по локальным компам. И мне плевать сколько юзер сделал у себя коммитов в игрушечном репозитории.

V>·>Да пожалуйста, если хочешь. Если кто-то тебе запретил, скажи, что я разрешаю.
V>Ваша секта именно что навязывает эту идеалогию, нечего здесь кривляться якобы что ты здесь ни причём.
Бедненький... не больно? Но ты борись!

V>>>Я пока одни глупости про свн от тебя слышу.

V>·>Ну да, глупости. А что поделаешь, я тебе тупо официальную доку svn цитирую и перевожу.
V>Ты хотя бы вдумывайся для кого она написана и что там написано.
Вдумался. А по делу-то есть что сказать?

V>>>разберись сначала с простой системой типа свн.

V>·>Так ты разобрался с DAG? Как хоть это расшифровывается? И есть ли он в svn или там что-то другое?
V>Да мне плевать, вот честно.
Мракобесие это называется.

V>>>Такая что тебе общий файл нужен на выходе, а не их разница.

V>·>А что по-твоему является результатом операции "apply the differences"?
V>Алгоритм не обязан apply differences делать, у него на входе целые файлы.
Ок. Что делает команда svn merge по-твоему? И, пожалуйста, не будь голословен, подтверди свой ответ цитатами/ссылками.

V>>>Ну да, это он делает для хранения истории изменений.

V>·>Что "это"?? Причём тут вообще хранение истории?
V>Притом что это имеет смысл в случае хранения, в случае слияния это не обязательно так. Просто в случае поиска коллизий именно в текстовых файлах, удобнее их пользователю в читаемом виде показывать.
Ну так а как? Опиши алгоритм что делает svn merge.

V>>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

V>·>Перечисли плиз, _со ссылкой на доку svn_.
V>С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
Ок, ссылка на учебник или исходники svn тоже сгодится.

V>>>Мерж это слияние контента файлов и дерева файлов/каталогов, плюс для свн, свойств файлов. А также автоматическое разрешение коллизий с ручным управлением в случае коллизий.

V>·>Это общие слова. А как конкретно это работает в svn?
V>Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.
Это понятно. Но дело нулевое — что именно умеет конкретная vcs. Так ты знаешь как это конкретно работает в svn?

V>>>У сорсфоржа с управлением хуже. К тому же оно выглядит и ощущается перегруженным.

V>·>Так почему хуже-то? Ну сделали бы sourceforge2.0 с лучшим управлением и чтобы выглядело разгруженным, в чём проблема-то?
V>Так это не имеет отношения к vcs, что я тебе и пытаюсь здесь объяснить.
Я знаю что пытаешься, но у тебя плохо получается. Так к чему имеет?

V>>>У гитхаба это сделано много проще. К примеру, не все хотят делать отдельный архив с исходниками/бинарниками и заливать его отдельно. В гитхабе это просто кнопка download на репозитории с автоматическим архивированием содержимого.

V>·>Это конкретно не заслуга github, а фича git, читай доку по "git archive". Думай дальше.
V>Заслуга в том, что они сделали простое управление со списком коммитов и кнопкой.
Что помешало в сорсфордже сделать такой же список и кнопку?

V>В сорсфорже по-другому, там надо изначально самому архив создать и залить.

Кстати, нет. Там есть кнопочка "Download snapshot".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[31]: факапы на работе
От: · Великобритания  
Дата: 19.04.17 20:47
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Ну, к примеру, ms использует свой TFS или как там оно, который до этого был SourceSafe.

V>·>TFS вообще-то не vcs. TFS может использовать и git. Ты наверное с TFVC попутал. А так с недавнего времени (мы ж о трендах?) внезапно: "Git is the default version control provider for new projects".
V>Это маркетинг.

Here at Microsoft we have teams of all shapes and sizes, and many of them are already using Git or are moving that way.

Вот тебе, бабушка, и маркетинг!
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: факапы на работе
От: Vain Россия google.ru
Дата: 20.04.17 00:44
Оценка:
Здравствуйте, ·, Вы писали:

V>>Это маркетинг.

·>

Here at Microsoft we have teams of all shapes and sizes, and many of them are already using Git or are moving that way.

·>Вот тебе, бабушка, и маркетинг!
Угу:

However, we also have a handful of teams with repos of unusual size! For example, the Windows codebase has over 3.5 million files and is over 270 GB in size. The Git client was never designed to work with repos with that many files or that much content. You can see that in action when you run “git checkout” and it takes up to 3 hours, or even a simple “git status” takes almost 10 minutes to run. That’s assuming you can get past the “git clone”, which takes 12+ hours.

Где тут гит вообще нормально справляется? Да с таким "справляется" сразу на помоечку. А ещё в соседней ветке на Pеrforce плевались.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[60]: факапы на работе
От: Vain Россия google.ru
Дата: 20.04.17 01:03
Оценка:
Здравствуйте, ·, Вы писали:

V>>>>А вот уже в общий транк хочешь не хочешь, а мержить придётся.

V>>·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.

·>Ну потому и "не хочешь", т.к. не умеешь.


V>>>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

V>>·>Перечисли плиз, _со ссылкой на доку svn_.
V>>С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
·>Ок, ссылка на учебник или исходники svn тоже сгодится.
Я же тебя не нанимался обучать, исходники в зубы и вперёд!

V>>Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.

·>Это понятно. Но дело нулевое — что именно умеет конкретная vcs. Так ты знаешь как это конкретно работает в svn?
Как это разрешит твои проблемы неумения пользоваться простым инструментом?

V>>В сорсфорже по-другому, там надо изначально самому архив создать и залить.

·>Кстати, нет. Там есть кнопочка "Download snapshot".
Я про Summary и Files. Туда надо отдельно заливать.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[61]: факапы на работе
От: · Великобритания  
Дата: 20.04.17 07:57
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>·>Ты говоришь как будто это что-то плохое. Сделал ревью, выглядит хорошо — нажал кнопочку — оно и замержилось за долю секунды. Это ж не svn, где так называемый "merge" это целое приключение.

V>

V>·>Ну потому и "не хочешь", т.к. не умеешь.

?

V>>>>>А алгоритмов слить 1/2/100500 файлов в один я думаю найдётся масса.

V>>>·>Перечисли плиз, _со ссылкой на доку svn_.
V>>>С чего ты взял что в доке рассказано про внутренние алгоритмы свн?
V>·>Ок, ссылка на учебник или исходники svn тоже сгодится.
V>Я же тебя не нанимался обучать, исходники в зубы и вперёд!
Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
Ну ладно, назови хоть штуки три из "массы".

V>>>Щито? Это вообще суть мержа, т.е. его цель. То что дано получить имея что-то, а как это будет достигнуто — дело десятое.

V>·>Это понятно. Но дело нулевое — что именно умеет конкретная vcs. Так ты знаешь как это конкретно работает в svn?
V>Как это разрешит твои проблемы неумения пользоваться простым инструментом?
Отлично разрешит, обо мне не беспокойся. Так как svn merge работает?

V>Я про Summary и Files. Туда надо отдельно заливать.

А, ясно. Но всё равно ты так и не объяснил почему такое же не сделали.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[62]: факапы на работе
От: Vain Россия google.ru
Дата: 20.04.17 09:38
Оценка:
Здравствуйте, ·, Вы писали:

V>>Я же тебя не нанимался обучать, исходники в зубы и вперёд!

·>Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.

V>>Как это разрешит твои проблемы неумения пользоваться простым инструментом?

·>Отлично разрешит, обо мне не беспокойся. Так как svn merge работает?
Там где надо, прекрасно работает. У тех кто не умеет — не работает.

V>>Я про Summary и Files. Туда надо отдельно заливать.

·>А, ясно. Но всё равно ты так и не объяснил почему такое же не сделали.
Потому-что они "особенные".
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[63]: факапы на работе
От: · Великобритания  
Дата: 20.04.17 10:00
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Я же тебя не нанимался обучать, исходники в зубы и вперёд!

V>·>Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.
V>С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.
У меня проблем с мержем нет, не беспокойся ты так обо мне.
Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[64]: факапы на работе
От: Vain Россия google.ru
Дата: 20.04.17 10:06
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>Я их читал, в отличие от тебя. Фантазировать и балаболить я тебя тоже не нанимал.

V>>С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.
·>У меня проблем с мержем нет, не беспокойся ты так обо мне.
Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[65]: факапы на работе
От: · Великобритания  
Дата: 20.04.17 10:15
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>С чего я должен тебе здесь верить, если ты показал свою профнепригодность в пользовании свн? Это у тебя проблемы с мержем а не у меня.

V>·>У меня проблем с мержем нет, не беспокойся ты так обо мне.
V>Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[66]: факапы на работе
От: Vain Россия google.ru
Дата: 20.04.17 13:16
Оценка:
Здравствуйте, ·, Вы писали:

V>>·>У меня проблем с мержем нет, не беспокойся ты так обо мне.

V>>Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
·>Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.
Мои "нулевые" знания помогли мне разобраться с свн и использовать его на ура. Твои "ненулевые" тебе не помогли. Так что сам можешь начинать с азов.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[67]: факапы на работе
От: · Великобритания  
Дата: 20.04.17 13:40
Оценка:
Здравствуйте, Vain, Вы писали:

V>Здравствуйте, ·, Вы писали:


V>>>·>У меня проблем с мержем нет, не беспокойся ты так обо мне.

V>>>Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
V>·>Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.
V>Мои "нулевые" знания помогли мне разобраться с свн и использовать его на ура. Твои "ненулевые" тебе не помогли. Так что сам можешь начинать с азов.
Какой ужас. Ты меня побил как ребёнка. Сдаюсь. Ты гигант мысли, гениальнеший гений.
О Величайший, с твоими сверхспособностями тебе не доставит труда перечислить алгоритмы svn merge, я надеюсь? Перечисли штук пять хотя бы. Ведь их "найдётся масса".
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[68]: факапы на работе
От: Vain Россия google.ru
Дата: 20.04.17 22:29
Оценка:
Здравствуйте, ·, Вы писали:

V>>Мои "нулевые" знания помогли мне разобраться с свн и использовать его на ура. Твои "ненулевые" тебе не помогли. Так что сам можешь начинать с азов.

·>Какой ужас. Ты меня побил как ребёнка. Сдаюсь. Ты гигант мысли, гениальнеший гений.
·>О Величайший, с твоими сверхспособностями тебе не доставит труда перечислить алгоритмы svn merge, я надеюсь? Перечисли штук пять хотя бы. Ведь их "найдётся масса".
Всё ребячество одолевает?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[69]: факапы на работе
От: · Великобритания  
Дата: 20.04.17 22:32
Оценка:
Здравствуйте, Vain, Вы писали:

V>>>Мои "нулевые" знания помогли мне разобраться с свн и использовать его на ура. Твои "ненулевые" тебе не помогли. Так что сам можешь начинать с азов.

V>·>Какой ужас. Ты меня побил как ребёнка. Сдаюсь. Ты гигант мысли, гениальнеший гений.
V>·>О Величайший, с твоими сверхспособностями тебе не доставит труда перечислить алгоритмы svn merge, я надеюсь? Перечисли штук пять хотя бы. Ведь их "найдётся масса".
V>Всё ребячество одолевает?
Меня, конечно, удивляет чем моя личность тебя так заинтересовала, что ты не перестаёшь думать и беспокоиться обо мне, но это не является темой этого форума, поэтому я закругляюсь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[70]: факапы на работе
От: Vain Россия google.ru
Дата: 21.04.17 20:47
Оценка:
Здравствуйте, ·, Вы писали:

V>>Всё ребячество одолевает?

·>Меня, конечно, удивляет чем моя личность тебя так заинтересовала, что ты не перестаёшь думать и беспокоиться обо мне, но это не является темой этого форума, поэтому я закругляюсь.
Я гналась за Вами чтобы сказать Вам как Вы мне безразличны? (C)
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Re[67]: факапы на работе
От: Dziman США http://github.com/Dziman
Дата: 21.04.17 21:51
Оценка:
Здравствуйте, Vain, Вы писали:

V>Здравствуйте, ·, Вы писали:


V>>>·>У меня проблем с мержем нет, не беспокойся ты так обо мне.

V>>>Зачем тогда ты про мерж в свн плачишься? Если у тебя не было проблем, ты бы их не выставлял на всеобщее обозрение.
V>·>Я тебе задаю конкретный вопрос. Список алгоритмов мержа в студию, которые умеет svn merge. Я тебе даже помогу, раз у тебя вообще нулевые знания. Вот начни отсюда и попробуй подумать и выбрать те, которые умеет svn merge.
V>Мои "нулевые" знания помогли мне разобраться с свн и использовать его на ура. Твои "ненулевые" тебе не помогли. Так что сам можешь начинать с азов.
Поверчностно наблюдаю всю ветку ваших споров: твоя позиция похожа на "я так привык и ничего больше знать не хочу"
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[68]: факапы на работе
От: Vain Россия google.ru
Дата: 22.04.17 01:18
Оценка:
Здравствуйте, Dziman, Вы писали:

D>Поверчностно наблюдаю всю ветку ваших споров: твоя позиция похожа на "я так привык и ничего больше знать не хочу"

Товарищ сам мне доказывает что свн у него не работает, причём здесь знать не хочу?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.