[image]

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

 
1 15 16 17 18 19 20 21

Kernel3

аксакал

Murkt> Просто не надо переносить привычки с централизованной системы на распределённую. Исправил - закоммитил. Это очень облегчает жизнь :)
При багфиксинге - да. При написании нового функционала - нет.
   

Murkt

Pythoneer

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

Murkt>> Только вот в SVN'е это получается один единственный коммит с туевой хучей изменений, в котором крайнего не найдёшь.
Kernel3> Совершенно не проблема, ИМХО.
Опять отличная аргументация. Это - проблема, ИМО.

Murkt>> Автоматизированные тесты работают всегда, а QA, как и в случае с SVN'ом, тестирует только главную ветку, или какую-нибудь мегабольшую и меганужную фичу. Одновременно в разработке не бывает пятьдесят мегабольших и меганужных фич, не так ли?
Kernel3> 50 - нет, а пяток - запросто.
Совершенно не проблема, ИМХО ©

Murkt>> Ничего он не подбирает, он её сам написал.
Kernel3> Ааа. Значит, готовую не нашёл и решил проблему так. Молодец.
Так когда он её писать начинал, особо-то и не было ничего хорошего (2005 год). Две самых популярных на сегодня DVCS - git и Mercurial, их начали разрабатывать с временной разницей около двух недель.

Murkt>> SVN-чекаут этой части занимает восемьдесят мегабайт.
Kernel3> И? Это, по-твоему, много? :)
Меньше, чем за год? Достаточно немало.
   

Murkt

Pythoneer

Murkt>> Просто не надо переносить привычки с централизованной системы на распределённую. Исправил - закоммитил. Это очень облегчает жизнь :)
Kernel3> При багфиксинге - да. При написании нового функционала - нет.
Разве «исправил» относится к написанию нового функционала?
   

Kernel3

аксакал

Murkt> Ну так синхронизируйся по большим шагам, если тебе так больше нравится.
Так и синхронизуюсь. И не вижу преимуществ распределённой системы в этом случае.
Murkt> Опять отличная аргументация. Это - проблема, ИМО.
Вот и поговорили © :)
Murkt> Совершенно не проблема, ИМХО ©
В случае централизованной СКВ - да :P
Murkt> Так когда он её писать начинал, особо-то и не было ничего хорошего (2005 год).
?? Аа, централизованные не считаем из принципа? :)
Murkt> Меньше, чем за год? Достаточно немало.
Безотносительно времени. Переход на Mercurial был вызван именно объёмом? Дык, 80Мб - это не объём :P
   

Kernel3

аксакал

Murkt> Разве «исправил» относится к написанию нового функционала?
А под "исправил" можно разные вещи понимать. Потому и уточнил :)
   

Murkt

Pythoneer

Murkt>> Ну так синхронизируйся по большим шагам, если тебе так больше нравится.
Kernel3> Так и синхронизуюсь. И не вижу преимуществ распределённой системы в этом случае.
В случае больших коммитов в централизованной СКВ у тебя нет более мелких шагов, и если ты что-то где-то пропустил, то отследить в каком именно месте сломалось гораздо сложнее. У тебя есть большой коммит, в котором куча изменений... Давай, рыскай по трём десяткам файлов и сотне изменений и ищи, где же там всё-таки была ошибка.

Murkt>> Опять отличная аргументация. Это - проблема, ИМО.
Kernel3> Вот и поговорили © :)
Ну дык. Вам там не надо искать, где же была допущена ошибка - у вас все пишут без ошибок. Или их потом QA находит и указывает с точностью до строки в файле? :F

Murkt>> Совершенно не проблема, ИМХО ©
Kernel3> В случае централизованной СКВ - да :P
В случае распределённой СКВ - тем более.

Murkt>> Так когда он её писать начинал, особо-то и не было ничего хорошего (2005 год).
Kernel3> ?? Аа, централизованные не считаем из принципа? :)
Централизованные Линусу не нравятся, и не нравились.

Murkt>> Меньше, чем за год? Достаточно немало.
Kernel3> Безотносительно времени. Переход на Mercurial был вызван именно объёмом? Дык, 80Мб - это не объём :P
Нет, как раз относительно времени. Переход был вызван большой активностью разработки и огромными трудностями со слиянием веток в сабвершене.
   

Kernel3

аксакал

Murkt> В случае больших коммитов в централизованной СКВ у тебя нет более мелких шагов, и если ты что-то где-то пропустил, то отследить в каком именно месте сломалось гораздо сложнее. У тебя есть большой коммит, в котором куча изменений... Давай, рыскай по трём десяткам файлов и сотне изменений и ищи, где же там всё-таки была ошибка.
Эээ... Ещё раз: в моём случае мелких шагов быть и не должно. Один большой коммит ака транзакция. А то запустят сборку билда после очередного "мелкого шага" и получится фигня.
Murkt> Ну дык. Вам там не надо искать, где же была допущена ошибка - у вас все пишут без ошибок. Или их потом QA находит и указывает с точностью до строки в файле, где ошибка? :F
Нет. У нас QA добивается повторяемости бага, а где он, ищет автор кода. С помощью отладчика. И мне почему-то казалось, что так везде. У вас не так? :F
Murkt>>> Совершенно не проблема, ИМХО ©
Murkt> В случае распределённой СКВ - тем более.
"Тем болеенность" в чём заключается? :)
Murkt> Нет, как раз относительно времени. Переход был вызван большой активностью разработки и огромными трудностями со слиянием веток в сабвершене.
Всё равно непонятно. На моей предыдущей работе CVS head был объёмом больше гига. И это текстовые исходники, картинок и прочих бинарных ресурсов было мало. Написано это всё было за 5-6 лет. Динамика даже покруче получается. И при этом переходить хотели на ClearCase, вариант РСКВ даже не рассматривался. Идиоты, наверное :)
   

Murkt

Pythoneer

Murkt>> В случае больших коммитов в централизованной СКВ у тебя нет более мелких шагов, и если ты что-то где-то пропустил, то отследить в каком именно месте сломалось гораздо сложнее. У тебя есть большой коммит, в котором куча изменений... Давай, рыскай по трём десяткам файлов и сотне изменений и ищи, где же там всё-таки была ошибка.
Kernel3> Эээ... Ещё раз: в моём случае мелких шагов быть и не должно. Один большой коммит ака транзакция. А то запустят сборку билда после очередного "мелкого шага" и получится фигня.
Ага. Это никак не противоречит тому, что я сказал. У вас там мелкие шаги порицаются, потому что могут всё поломать, но большие шаги являются неудобными с точки зрения поиска бага.

Murkt>> Ну дык. Вам там не надо искать, где же была допущена ошибка - у вас все пишут без ошибок. Или их потом QA находит и указывает с точностью до строки в файле, где ошибка? :F
Kernel3> Нет. У нас QA добивается повторяемости бага, а где он, ищет автор кода. С помощью отладчика. И мне почему-то казалось, что так везде. У вас не так? :F
Не так - отладчиком искать долго. Он идёт в бой, когда другие, более быстрые методы не помогли найти источник проблемы. Но у вас, из-за централизованного репозитория и больших коммитов более быстрые методы просто недоступны.

Murkt>> В случае распределённой СКВ - тем более.
Kernel3> "Тем болеенность" в чём заключается? :)
Можно тестировать нужную ветку (нужную фичу), не обращая внимания на то, что всё могут поломать другие большие и важные фичи. И когда появился глюк, то ты точно знаешь, кто это напакостил :)

Murkt>> Нет, как раз относительно времени. Переход был вызван большой активностью разработки и огромными трудностями со слиянием веток в сабвершене.
Kernel3> Всё равно непонятно. На моей предыдущей работе CVS head был объёмом больше гига. И это текстовые исходники, картинок и прочих бинарных ресурсов было мало. Написано это всё было за 5-6 лет. Динамика даже покруче получается. И при этом переходить хотели на ClearCase, вариант РСКВ даже не рассматривался. Идиоты, наверное :)
Наверное. Мазохисты даже, я бы сказал.
   

Kernel3

аксакал

Murkt> Ага. Это никак не противоречит тому, что я сказал. У вас там мелкие шаги порицаются, потому что могут всё поломать, но большие шаги являются неудобными с точки зрения поиска бага.
Дык, сломанный билд приводит к бОльшим потерям времени.
Murkt> Не так - отладчиком искать долго. Он идёт в бой, когда другие, более быстрые методы не помогли найти источник проблемы.
Murkt> Но у вас, из-за централизованного репозитория и больших коммитов более быстрые методы просто недоступны.
Ну вы, блин, даёте (с) :) От решаемых задач зависит, видимо. В нашем случае отладчик - самый быстрый способ. А конкретно в моём - так и практически единственный.
Murkt> Наверное. Мазохисты даже, я бы сказал.
:) :) :)
   
+
-
edit
 

Kernel3

аксакал

В общем, я хочу сказать, что в "самом общем" случае у РСКВ особых преимуществ нет. Вот :)
   

Murkt

Pythoneer

Murkt>> Ага. Это никак не противоречит тому, что я сказал. У вас там мелкие шаги порицаются, потому что могут всё поломать, но большие шаги являются неудобными с точки зрения поиска бага.
Kernel3> Дык, сломанный билд приводит к бОльшим потерям времени.
Приводит, я ж не отрицаю. Потому и используют в централизованных системах большие шаги. На всякий случай, повторю, что в распределённых системах мелкие шаги не приводят к поломке билда.

Murkt>> Не так - отладчиком искать долго. Он идёт в бой, когда другие, более быстрые методы не помогли найти источник проблемы.
Murkt>> Но у вас, из-за централизованного репозитория и больших коммитов более быстрые методы просто недоступны.
Kernel3> Ну вы, блин, даёте (с) :) От решаемых задач зависит, видимо. В нашем случае отладчик - самый быстрый способ. А конкретно в моём - так и практически единственный.
Ну вот - я же говорю, что более быстрые методы вам просто недоступны. Естественно, что отладчик тогда самый быстрый.


Kernel3> В общем, я хочу сказать, что в "самом общем" случае у РСКВ особых преимуществ нет. Вот :)
«Пастернака не читал, но осуждаю». Как раз в самых общих случаях у РСКВ преимуществ масса, только ты их упорно не хочешь видеть :)
   

Kernel3

аксакал

Murkt> На всякий случай, повторю, что в распределённых системах мелкие шаги не приводят к поломке билда.
Ага. Они приводят к отсутствию центрального билда как такового и потерях времени на согласование с QA, что и в каком порядке им надо тестировать :)
Murkt> Ну вот - я же говорю, что более быстрые методы вам просто недоступны.
Ну, вот возьмём системный сервис с N потоками и попробуем найти в нём багу "глазками", пусть даже не по всем исходникам, а только разнице между рабочей копией и предыдущим коммитом... Гм... Да... А ещё такие страшные вещи, как драйвера, бывают :)
Murkt> «Пастернака не читал, но осуждаю». Как раз в самых общих случаях у РСКВ преимуществ масса, только ты их упорно не хочешь видеть :)
Раз не подходит для моего частного случая, то в "самом общем" преимуществ быть не может по определению :)
   
Это сообщение редактировалось 27.03.2008 в 23:12
27.03.2008 23:17, Murkt: -1: за "мега-аргументацию"

Murkt

Pythoneer

Murkt>> На всякий случай, повторю, что в распределённых системах мелкие шаги не приводят к поломке билда.
Kernel3> Ага. Они приводят к отсутствию центрального билда как такового и потерях времени на согласование с QA что и в каком порядке им надо тестировать :)
О Б-же. Почитай всё внимательно.

Murkt>> Ну вот - я же говорю, что более быстрые методы вам просто недоступны.
Kernel3> Ну, вот возьмём системный сервис с N потоками и попробуем найти в нём багу "глазками", пусть даже не по всем исходникам, а только разнице между рабочей копией и предыдущим коммитом... Гм... Да... А ещё такие страшные вещи, как драйвера, бывают :)
Если коммиты маленькие, то багу найти гораздо проще. Поменялось три-пять строк - посмотрел и увидел. Хотя от специфики зависит, конечно. На каком-нибудь Си «небольшие коммиты» наверняка не по пять строк, если это не исправление опечатки. Но, раз у меня таких проблем не было, то и в основном их ни у кого не бывает, а значит париться не стоит.

Murkt>> «Пастернака не читал, но осуждаю». Как раз в самых общих случаях у РСКВ преимуществ масса, только ты их упорно не хочешь видеть :)
Kernel3> Раз не подходит для моего частного случая, то в "самом общем" преимуществ быть не может по определению :)
Четвёртый раз мега-аргументация. Или уже пятый?
   
07.04.2008 10:57, Kernel3: -1: за далпайопство

Kernel3

аксакал

Murkt> Но, раз у меня таких проблем не было, то и в основном их ни у кого не бывает, а значит париться не стоит.
Неее, вот это - мега-аргументация :) :)
   

Kernel3

аксакал

Kernel3>> Раз не подходит для моего частного случая, то в "самом общем" преимуществ быть не может по определению :)
Murkt> Четвёртый раз мега-аргументация. Или уже пятый?
Я просто под "самым общим" имею ввиду именно "самый общий", а не "самый средний" :)
   

Murkt

Pythoneer

Murkt>> Но, раз у меня таких проблем не было, то и в основном их ни у кого не бывает, а значит париться не стоит.
Kernel3> Неее, вот это - мега-аргументация :) :)
Так я просто повторил твои же слова.
   
+
-
edit
 

john5r

аксакал
★★☆
о какой же я тупой лошара... ыыыыыы... то-то я удивился что двуслойные дивидишки получилось найти по дешевке. Они ***дь никакие не двуслойные! они оказались тупо двусторонние!

и как мне на них копировать двуслойные дивиди? правильно, по-человечески никак. Так что придется раскошеливаться...
   
+
-
edit
 

Balancer

администратор
★★★★★
john5r> Они ***дь никакие не двуслойные! они оказались тупо двусторонние!

Ы! :D Ни разу в продаже не видел, только уже записанные фильмы :)
   
RU Bums #29.03.2008 00:38  @Алдан-3#25.03.2008 09:02
+
-
edit
 

Bums
xo

аксакал

Алдан-3> Пытаюсь восстановить хоть что-то с рухнувшего мобильного харда на 100 Гб.

Эх, а мой WD на 120Гб в воскресенье подрезали на работе... :(
   
RU Dem_anywhere #29.03.2008 02:05
+
-
edit
 

Dem_anywhere

аксакал
★☆
Поставил себе Microsoft XML Paper Specification Essentials Pack. Забавно.
С удивлением обнаружил в инф-файле следующее
;----Supported Products
OS_NT4 = "Windows NT 4"
OS_W2K = "Windows 2000"
OS_W2K_SP2 = "Windows 2000 Service Pack 2"
OS_W2K_SP3 = "Windows 2000 Service Pack 3"
OS_W2K_SP4 = "Windows 2000 Service Pack 4"
OS_W2K_SP5 = "Windows 2000 Service Pack 5"
OS_WXP = "Windows XP"
OS_WXP_SP1 = "Windows XP Service Pack 1"
OS_WXP_SP2 = "Windows XP Service Pack 2"
OS_WXP_SP3 = "Windows XP Service Pack 3"
OS_WXP_SP4 = "Windows XP Service Pack 4"
OS_WXP_SP5 = "Windows XP Service Pack 5"
OS_W2K3 = "Windows Server 2003"
OS_W2K3_SP1 = "Windows Server 2003 Service Pack 1"
OS_W2K3_SP2 = "Windows Server 2003 Service Pack 2"
OS_W2K3_SP3 = "Windows Server 2003 Service Pack 3"
OS_W2K3_SP4 = "Windows Server 2003 Service Pack 4"
OS_W2K3_SP5 = "Windows Server 2003 Service Pack 5"
   

Murkt

Pythoneer

Ну так с запасом на будущее.
   
+
-
edit
 

Mishka

модератор
★★★
ИМХО, на каждый продукт планируется, как правило, определённое максимальное количество сервис паков. Имена забиваются. Стараются уложиться в меньшее количество за время жизни пакета.
   
+
-
edit
 

AlleyCat

втянувшийся
john5r> о какой же я тупой лошара... ыыыыыы... то-то я удивился что двуслойные дивидишки получилось найти по дешевке. Они ***дь никакие не двуслойные! они оказались тупо двусторонние!
john5r> и как мне на них копировать двуслойные дивиди? правильно, по-человечески никак. Так что придется раскошеливаться...

DVD Fab Platinum юзай
   
UA AlleyCat #29.03.2008 19:46  @Balancer#27.03.2008 23:55
+
-
edit
 

AlleyCat

втянувшийся
john5r>> Они ***дь никакие не двуслойные! они оказались тупо двусторонние!
Balancer> Ы! :D Ни разу в продаже не видел, только уже записанные фильмы :)

У нас специально прайсе капсом выделено для жадных товарищей.

Disk, DVD+R СМС 9.4Gb DOUBLE 8х Spin 50pcs (side A/side B) black ДВУХСТОРОННИЕ!!!!!! 0 115,44
Disk, DVD+R СМС 9.4Gb DOUBLE 8х Spin 50pcs (side A/side B) white ДВУХСТОРОННИЕ!!!!!! 0 115,44
   
+
-
edit
 

Последние действия над темой
1 15 16 17 18 19 20 21

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