[image]

Кто что делает - компутерный вариант (2)

 
1 15 16 17 18 19 20 21

Murkt

Pythoneer

Я не пользуюсь командой update, поэтому ошибиться не смогу :)
   
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> Я не пользуюсь командой update, поэтому ошибиться не смогу :)

А обновляешь как текущий репозиторий?
   
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> hg pull -u


Это, разве не то же самое, что hg pull && hg up ?
   

Murkt

Pythoneer

Гмгм... Чёрт его знает. Я всегда коммичу перед апдейтом :) Потому что после апдейта всё равно придётся делать мерж, и изменения окажутся закоммичеными, только будет очень сложно разобраться что к чему.
   
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> Я всегда коммичу перед апдейтом :)

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

А с hg получается - либо делаешь апдейт и теряешь модификации, либо сперва коммитишь, а потом - апдейт, а всё время до проверки в репозитории потенциально нерабочий код.

В одиночку работать - нормально. В команде - кранты :)
   
+
-
edit
 

Kernel3

аксакал

Balancer> А правильный стиль такой - затаскиваешь к себе обновления в репозитории, проверяешь на работоспособность получившегося и только потом - коммитишь.
Именно :)
Balancer> В одиночку работать - нормально. В команде - кранты :)
+1! +1! :F
   

Murkt

Pythoneer

Налицо явное непонимание принципов работы с распределёнными СКВ.

Есть у нас какой-то большой проект, и в «первый» момент времени у всех разработчиков версия одна и та же. Та версия, которая лежит в серверном репозитории. Нам нужно сделать какую-нибудь мелкую фичу. Например, возможность смотреть непрочитанные сообщения только в определённых форумах :)

Мы подумали, как оно должно быть, написали модельку для ORM'а, закоммитили (в наш локальный репозиторий, не в центральный). Побаловались с моделькой в консоли, поменяли код для обработки запроса «непрочитанные сообщения» от юзера, подёргали его в консольке по-всякому, закоммитили. Добавили шаблон и контроллер для настройки всего этого дела в профиле, подёргали, закоммитили. Написали пачку тестов (какой там TDD, что вы говорите! :D), закоммитили. О! Написали скрипт для апгрейда/даунгрейда схемы БД, закоммитили. Запустили всю пачку тестов, нашли пару багов, исправили, закоммитили. Работа над самой фичей уже закончена. Проверяем серверный репозиторий - там появились изменения от других разработчиков. Пуллим их к себе, фиксим конфликты (если есть), запускаем все тесты, фиксим баги (они могли появиться на стыке наших и их изменений). Коммитим новую ревизию, мерж. До этого момента вся наша работа проходила в нашем личном репозитории, а в «центральном» всё было отлично - там появляются уже полностью готовые, оттестированые вещи. И вот только после того, как всё сделано, смержено - вот только сейчас делаем hg push, и заливаем наши изменения на сервер в репозитории.

Такой workflow значительно облегчает разработку в больших командах. Как вы думаете, Mozilla переехала с SVN на Меркуриал потому, что меркуриал «в команде - кранты»? Почему linux kernel разрабатывают при помощи РСКВ (git)? Компания, в которой я работал (mydeco.com | Shop Unique Range Of Furniture, Home Accessories & Gifts ), с понедельника перевела репозиторий веб-части на Меркуриал.
   
Это сообщение редактировалось 27.03.2008 в 19:44
+
-
edit
 

Balancer

администратор
★★★★★
Ты приводишь пример не большого проекта, а ОЧЕНЬ БОЛЬШОГО ПРОЕКТА :) Это уже несколько иная история. Но даже там, VCS, которая способна в одночасье и без предупреждения убить результат долгой работы - это бяка. Могла бы хотя бы спросить - «У вас тут локальные файлы модифицированы, я их сейчас убью. Продолжать? [y/n]»
   

Kernel3

аксакал

Murkt> Нам нужно сделать какую-нибудь мелкую фичу. Например, возможность смотреть непрочитанные сообщения только в определённых форумах :)
А если фича немелкая? И критически важная для новой версии? И коммитить её, соответственно, надо полноценными транзакциями, соблюдая когерентность кучи файлов между собой?
Murkt> Мы подумали, как оно должно быть, написали модельку для ORM'а, закоммитили (в наш локальный репозиторий, не в центральный). Побаловались с моделькой в консоли... запускаем все тесты, фиксим баги (они могли появиться на стыке наших и их изменений).
А QA не офигеет от такого количества разных сборок? Или build acceptance test на этой стадии просто нет?
Murkt> Как вы думаете, Mozilla переехала с SVN на Меркуриал потому, что меркуриал «в команде - кранты»?
Вот уж Мозилла с её глюками лично меня совсем не интересует :)
Murkt> Почему linux kernel разрабатывают при помощи РСКВ (git)?
Вот это уже интереснее :) Только, ЕМНИС, Линус периодически меняет СКВ. Подбирает оптимальную, видимо :F
Murkt> Компания, в которой я работал (http://www.mydeco.com/), с понедельника перевела репозиторий веб-части на Меркуриал.
Веб-части. Понятно, ага :)
   
RU Серокой #27.03.2008 19:07
+
-
edit
 

Серокой

координатор
★★★★
Тестик, хоть и не совсем про компы, но рядом:
   
RU Kernel3 #27.03.2008 19:08  @Серокой#27.03.2008 19:07
+
-
edit
 
RU Серокой #27.03.2008 19:11
+
-
edit
 

Серокой

координатор
★★★★
Касательно одного персонажа теста:
&nbsp[показать]
   
+
-
edit
 

Balancer

администратор
★★★★★
Kernel3> Баян :) У меня 9/10 :)
Kernel3> Тьфу, блин. Это другой баян :F В этом у меня 12/14 :)

У меня было что-то около 10 из 14. Сейчас результат сильно ухудшился :D


Нажмите, чтобы проверить себя »»
   
+
-
edit
 

Murkt

Pythoneer

Balancer> Ты приводишь пример не большого проекта, а ОЧЕНЬ БОЛЬШОГО ПРОЕКТА :) Это уже несколько иная история. Но даже там, VCS, которая способна в одночасье и без предупреждения убить результат долгой работы - это бяка. Могла бы хотя бы спросить - «У вас тут локальные файлы модифицированы, я их сейчас убью. Продолжать? [y/n]»
Мне вообще слабо верилось, что оно так делает... Проверил. Не делает. Ну не убивает оно мои изменения!

Некоторые команды я выкинул (по типу cd), и смержил две консоли в приблизительно хронологическом порядке.
code text
  1. D:\\test\\1>hg init
  2.  
  3. D:\\test\\1>hg add
  4. adding 1.txt
  5.  
  6. D:\\test\\1>hg ci -m "1.txt added"
  7.  
  8. D:\\test\\1>hg ci -m "1.txt modified"
  9.  
  10. D:\\test\\1>hg serve
  11. 127.0.0.1 - - [27/Mar/2008 18:08:04] "GET /?cmd=heads HTTP/1.1" 200 -
  12. 127.0.0.1 - - [27/Mar/2008 18:08:04] "GET /?cmd=changegroup&roots=0000000000000000000000000000000000000000 HTTP/1.1" 200 -
  13.  
  14. D:\\test>hg clone http://localhost:8000 2
  15. requesting all changes
  16. adding changesets
  17. adding manifests
  18. adding file changes
  19. added 2 changesets with 2 changes to 1 files
  20. 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  21.  
  22. D:\\test\\2>hg st
  23. ? 2.txt
  24.  
  25. D:\\test\\2>hg add
  26. adding 2.txt
  27.  
  28. D:\\test\\2>hg ci -m "2.txt added"
  29.  
  30. D:\\test\\1>hg st
  31. M 1.txt
  32.  
  33. D:\\test\\2>hg serve
  34. 127.0.0.1 - - [27/Mar/2008 18:09:23] "GET /?cmd=heads HTTP/1.1" 200 -
  35. 127.0.0.1 - - [27/Mar/2008 18:09:23] "GET /?nodes=bc9faaf59902d53fc5ee44762904fc4913990bb3&cmd=branches HTTP/1.1" 200 -
  36. 127.0.0.1 - - [27/Mar/2008 18:09:23] "GET /?pairs=bc9faaf59902d53fc5ee44762904fc4913990bb3-21149adbbf6955dcc1bda97188f6dba5825417aa&cmd=between HTTP/1.1" 200 -
  37. 127.0.0.1 - - [27/Mar/2008 18:09:23] "GET /?cmd=changegroup&roots=bc9faaf59902d53fc5ee44762904fc4913990bb3 HTTP/1.1" 200 -
  38.  
  39. D:\\test\\1>hg pull http://localhost:8000/
  40. pulling from http://localhost:8000/
  41. searching for changes
  42. adding changesets
  43. adding manifests
  44. adding file changes
  45. added 1 changesets with 1 changes to 1 files
  46. (run 'hg update' to get a working copy)
  47.  
  48. D:\\test\\1>hg update
  49. 1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  50.  
  51. D:\\test\\1>hg st
  52. M 1.txt
  53.  
  54. D:\\test\\1>hg log
  55. changeset:   2:bc9faaf59902
  56. tag:         tip
  57. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  58. date:        Thu Mar 27 18:08:43 2008 +0200
  59. summary:     2.txt added
  60.  
  61. changeset:   1:0579a8f7e4d4
  62. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  63. date:        Thu Mar 27 18:07:37 2008 +0200
  64. summary:     1.txt modified
  65.  
  66. changeset:   0:21149adbbf69
  67. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  68. date:        Thu Mar 27 18:07:16 2008 +0200
  69. summary:     1.txt added
  70.  
  71.  
  72. D:\\test\\1>hg ci -m "1.txt modified"
  73.  
  74. D:\\test\\1>hg log
  75. changeset:   3:384f6495a30b
  76. tag:         tip
  77. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  78. date:        Thu Mar 27 18:10:39 2008 +0200
  79. summary:     1.txt modified
  80.  
  81. changeset:   2:bc9faaf59902
  82. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  83. date:        Thu Mar 27 18:08:43 2008 +0200
  84. summary:     2.txt added
  85.  
  86. changeset:   1:0579a8f7e4d4
  87. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  88. date:        Thu Mar 27 18:07:37 2008 +0200
  89. summary:     1.txt modified
  90.  
  91. changeset:   0:21149adbbf69
  92. user:        Vsevolod Solovyov <vsevolod.solovyov@gmail.com>
  93. date:        Thu Mar 27 18:07:16 2008 +0200
  94. summary:     1.txt added
   

Murkt

Pythoneer

Murkt>> Нам нужно сделать какую-нибудь мелкую фичу. Например, возможность смотреть непрочитанные сообщения только в определённых форумах :)
Kernel3> А если фича немелкая? И критически важная для новой версии? И коммитить её, соответственно, надо полноценными транзакциями, соблюдая когерентность кучи файлов между собой?
Может ты удосужишься прочесть полностью моё сообщение? Полноценная транзакция - это и есть hg push в репозиторий, с которым все синхронизируются. Только вот в SVN'е это получается один единственный коммит с туевой хучей изменений, в котором крайнего не найдёшь. А здесь можно легко отследить каждое мелкое изменение.

Murkt>> Мы подумали, как оно должно быть, написали модельку для ORM'а, закоммитили (в наш локальный репозиторий, не в центральный). Побаловались с моделькой в консоли... запускаем все тесты, фиксим баги (они могли появиться на стыке наших и их изменений).
Kernel3> А QA не офигеет от такого количества разных сборок? Или build acceptance test на этой стадии просто нет?
Автоматизированные тесты работают всегда, а QA, как и в случае с SVN'ом, тестирует только главную ветку, или какую-нибудь мегабольшую и меганужную фичу. Одновременно в разработке не бывает пятьдесят мегабольших и меганужных фич, не так ли?

Murkt>> Как вы думаете, Mozilla переехала с SVN на Меркуриал потому, что меркуриал «в команде - кранты»?
Kernel3> Вот уж Мозилла с её глюками лично меня совсем не интересует :)
Аргумент, стопудово.

Murkt>> Почему linux kernel разрабатывают при помощи РСКВ (git)?
Kernel3> Вот это уже интереснее :) Только, ЕМНИС, Линус периодически меняет СКВ. Подбирает оптимальную, видимо :F
Ничего он не подбирает, он её сам написал.

Murkt>> Компания, в которой я работал (http://www.mydeco.com/), с понедельника перевела репозиторий веб-части на Меркуриал.
Kernel3> Веб-части. Понятно, ага :)
SVN-чекаут этой части занимает восемьдесят мегабайт. Всего остального кода и всех остальных разработчиков где-то втрое меньше, и они более-менее спокойно живут и с SVN'ом, тем более, что у них связанность гораздо меньше, и мержей там практически нет.
   
RU Ведмедь #27.03.2008 19:41
+
-
edit
 

Ведмедь

модератор
★★
У меня 57 %. Правда, последнего так и хотелось в убийцы записать :)
   
RU Серокой #27.03.2008 19:41  @Ведмедь#27.03.2008 19:41
+
-
edit
 

Серокой

координатор
★★★★
Ведмедь> последнего так и хотелось в убийцы записать :)
... рабочего времени? )
   
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> Мне вообще слабо верилось, что оно так делает... Проверил. Не делает.

Повторить сейчас не удалось. Но факт остаётся фактом - сегодня утром оно по hg pull && hg up снесло массу ночных обновлений. И пару раз натыкался на такие же потери на неделе, но по мелочи, поэтому и внимания не обращал. Где-то там подводный камень есть.
   
+
-
edit
 

Murkt

Pythoneer

Murkt>> Мне вообще слабо верилось, что оно так делает... Проверил. Не делает.
Balancer> Повторить сейчас не удалось. Но факт остаётся фактом - сегодня утром оно по hg pull && hg up снесло массу ночных обновлений. И пару раз натыкался на такие же потери на неделе, но по мелочи, поэтому и внимания не обращал. Где-то там подводный камень есть.
Просто не надо переносить привычки с централизованной системы на распределённую. Исправил - закоммитил. Это очень облегчает жизнь :)
   
+
-
edit
 

Balancer

администратор
★★★★★
Murkt> Просто не надо переносить привычки с централизованной системы на распределённую.

Просто как-то претит делать три репозитория на одной машине там, где можно обойтись двумя :)
   
RU Balancer #27.03.2008 19:55  @Balancer#27.03.2008 19:54
+
-
edit
 

Balancer

администратор
★★★★★
Balancer> Просто как-то претит делать три репозитория на одной машине там, где можно обойтись двумя :)

Хотя, торможу, двух и хватит. Просто привычка делать pull перед каждым up и push после каждого ci.
   
PT MIKLE #27.03.2008 20:01  @Ведмедь#27.03.2008 19:41
+
-
edit
 

MIKLE

старожил

Ведмедь> У меня 57 %. Правда, последнего так и хотелось в убийцы записать :)

стокаже. но на паре человек я ложанулся. будучи почти увереным тыкал еравильный ответ..
   
RU Ведмедь #27.03.2008 20:15
+
-
edit
 

Ведмедь

модератор
★★
Я пару раз также лажанулся...
   

Kernel3

аксакал

Murkt> Может ты удосужишься прочесть полностью моё сообщение?
А чего такой нервный? Тоже весенний авитоминоз?
Murkt> Полноценная транзакция - это и есть hg push в репозиторий, с которым все синхронизируются.
Ты не понял. Каждый день - полноценная транзакция. А то и несколько. Так бывает.
Т.е. не вся фича за раз, а таки по шагам. Но нефиговым таким шагам.
Murkt> Только вот в SVN'е это получается один единственный коммит с туевой хучей изменений, в котором крайнего не найдёшь.
Совершенно не проблема, ИМХО.
Murkt> Автоматизированные тесты работают всегда, а QA, как и в случае с SVN'ом, тестирует только главную ветку, или какую-нибудь мегабольшую и меганужную фичу. Одновременно в разработке не бывает пятьдесят мегабольших и меганужных фич, не так ли?
50 - нет, а пяток - запросто.
Kernel3>> Вот уж Мозилла с её глюками лично меня совсем не интересует :)
Murkt> Аргумент, стопудово.
О то ж.
Murkt> Ничего он не подбирает, он её сам написал.
Ааа. Значит, готовую не нашёл и решил проблему так. Молодец.
Murkt> SVN-чекаут этой части занимает восемьдесят мегабайт.
И? Это, по-твоему, много? :)
   
1 15 16 17 18 19 20 21

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru