Я могу предположить что иностранные гики
(а их поболе чем в ex-СССР и они в целом поактивнее) всё же откликнутся на призыв и какая то движуха будет.
Не сотни тысяч, конечно. Адвокатскому бюро, которое не за принципы работает а за деньги, смею думать что не маленькие, это будет как слону дробина.
Сам способ «наказания» — весьма мерзотный. Адвокаты — всего лишь инструмент медиа-корпораций. Люди с таким же успехом могут «наказывать» перфоратор соседа, который перфорирует стену в 6 утра.
Интересно, если запросить логотипы для «клиники нелегальной трансплантации» и «борделя с несовершеннолетней обслугой» — будет столько же ответов от исполнителей и такая же реакция от администрации портала?
ибо рынок онлайн-игр данного масштаба перенасыщен.
Это ОЧЕНЬ спорное утверждение.
В регионах только-только появляется безлимит за небольшие деньги,
да и стоит руВоВ дешевле.
Думаю - стоит ожидать орды детей :)
Хоть многих и коробит от всех этих Штормградов и
"штанов с духом мартышки", однако
imho в MMORPG главное - общение людей одного культурного слоя и
примерно одинакового контекста в процессе совместного убийства(зачёркнуто)
преодоления трудностей :)
А если при этом ещё и книжки тамошние почитывать а не скипать из-за лени...
Лично мне стало интереснее.
Ну могу я по английски общаться, но я вне их культуры и достаточно
много приколов и хохм понимаю не с первого раза :)
Не вариант вообще.
Слишком много телодвижений и, как следствие,
бардак. Проще всё же не "тулзы" использовать
а написать регламент по порядку внесения изменений
в БД и следовать ему,
выкладывая изменяющей стороной дампы И/ИЛИ SQL-скрипты,
актуализующие состояние БД.
Все, советующие всякого рода дбкомпареры - ответьте пожалуйста на один простой вопрос:
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)
Блин, цитата сломалась. В общем автору - вы путаете чекаут и импорт :)
Импорт - он для ДОБАВЛЕНИЯ в репозиторий, чекаут же - для создания рабочей копии на локальном компутере.
Не очень понятен смысл сей статьи, я бы рекомендовал читать оригинальные инструкции по установке :)
А что собственно вам надо - просмотр репозитария или управление багами ? ;)
Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
Опыт использования подобных инструментов для Oracle - весьма отрицательный
для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).
Причём, зачастую приходится отслеживать не только структуры - но и сами данные
(метаинфа, классификаторы и справочники).
В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
Можно модель базы хранить в репозитории и при коммитах указывать ревижн модели базы, который необходимо применить на данный ревижн.
Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)
(а их поболе чем в ex-СССР и они в целом поактивнее) всё же откликнутся на призыв и какая то движуха будет.
Не сотни тысяч, конечно. Адвокатскому бюро, которое не за принципы работает а за деньги, смею думать что не маленькие, это будет как слону дробина.
Сам способ «наказания» — весьма мерзотный. Адвокаты — всего лишь инструмент медиа-корпораций. Люди с таким же успехом могут «наказывать» перфоратор соседа, который перфорирует стену в 6 утра.
Интересно, если запросить логотипы для «клиники нелегальной трансплантации» и «борделя с несовершеннолетней обслугой» — будет столько же ответов от исполнителей и такая же реакция от администрации портала?
Впрочем, вопрос риторический.
:)
некоторая часть пользователей куда-нибудь свалит,
а другая часть будет продолжать качать клиенты.
пропорции произвольны :)
Хотя я не очень понимаю почему писатели мессенджеров не выделят протокол в библиотечку и не сделают автообновление.
Есть ведь и другие пути наживы на рекламе — например можно вставлять её в текст сообщений пользователей (допустим каждые 50 сообщений).
Возможно это будет раздражать людей, а возможно и не очень.
Это ОЧЕНЬ спорное утверждение.
В регионах только-только появляется безлимит за небольшие деньги,
да и стоит руВоВ дешевле.
Думаю - стоит ожидать орды детей :)
Хоть многих и коробит от всех этих Штормградов и
"штанов с духом мартышки", однако
imho в MMORPG главное - общение людей одного культурного слоя и
примерно одинакового контекста в процессе совместного убийства(зачёркнуто)
преодоления трудностей :)
А если при этом ещё и книжки тамошние почитывать а не скипать из-за лени...
Лично мне стало интереснее.
Ну могу я по английски общаться, но я вне их культуры и достаточно
много приколов и хохм понимаю не с первого раза :)
Слишком много телодвижений и, как следствие,
бардак. Проще всё же не "тулзы" использовать
а написать регламент по порядку внесения изменений
в БД и следовать ему,
выкладывая изменяющей стороной дампы И/ИЛИ SQL-скрипты,
актуализующие состояние БД.
Imho какой то сомнительный способ синхронизации баз для использования
в качестве решения.
Как разовый вариант - не спорю, полезная фича.
И, сия тулза сравнивает структуры или может и данные сравнивать?
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)
на английском :)
А вообще в TortoiseSVN(!) есть чудесная дока "Chapter 3. Setting Up A Server"
Рекомендую. :)
Импорт - он для ДОБАВЛЕНИЯ в репозиторий, чекаут же - для создания рабочей копии на локальном компутере.
Не очень понятен смысл сей статьи, я бы рекомендовал читать оригинальные инструкции по установке :)
3) Для скачки себе версии из существующего репозитория запускается пункт меню TortoiseSVN
Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
когда меняются интерфейсы\слои.
для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).
Причём, зачастую приходится отслеживать не только структуры - но и сами данные
(метаинфа, классификаторы и справочники).
В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)
Мержить в ручном режиме тоже.