Комментарии

Как организовать работу с системами контроля версий для разработки нескольких проектов с общей основой?

Стоит следующая задача: мне надо создать хранилище, где будут разные файлы скриптов (например, A). Также будет хранилище, где будет стандартный набор файлов для начала программирования сайта (например, B). Когда я создаю новый проект — создается новое хранилище (например, C).

Теперь мне нужно в С перенести стандартный набор из хранилища В. Потом мне нужно из А перенести 2 скрипта в С. После этого я вижу, что в стандартных файлах (которые хранятся в В) есть ошибка. Я её исправляю и хочу залить как на В, так и на С. И так далее. То есть мне надо с ними 3-мя работать одновременно.

Уже пробовал git и svn, ничего не получилось. Решение через git submodule не подходит, т.к. общие файлы нужно редактировать в конкретных проектах, и при этом иметь возможность подтягивать изменения в этих же файлах из основного набора.

В какой системе контроля версий и каким образом можно организовать хранилища для решения этой задачи?

Управление идентификацией в DRM — это управление атрибутами идентификации для обеспечения доступа к цифровому контенту. А насчет того какие типы DRM наиболее распространены, то тут наиболее распространенным типом DRM является программный DRM, который используется для защиты цифрового контента.

Возникло несколько вопросов, что такое управление идентификацией в DRM? и какие типы DRM наиболее распространены?

Отличная статья, мой личный опыт сосредоточен на шифровании DRM, технологиях CDN и оптимизации маркетинговых кампаний для стимулирования вовлеченности и роста. Используя VdoCipher я значительно улучшил цифровой опыт и участвовал в углубленных технических дискуссиях в секторах электронного обучения, медиа и безопасности, демонстрируя приверженность инновациям и совершенству в цифровой среде.

Ну все же есть и ещё одна причина — средняя скорость отклика по больнице. Мускуль несколько быстрее, особенно на интенсивных чтениях, MyISAM быстрее чем InnoDb, xtraDb, даже внутри самого мускуля, без Постгре… инмемори хранение… появилось в Постгре? не следил давно, ибо всё что попадается последнее время — проекты на Мускуле (Мария, Перкона..).

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

И это ещё одна причина предпочтения Мускулю: меньшие требования к ресурсам (дешевле сервер банально) для одних и тех же объемов и нагрузок. И кмк, совокупность (а не легкость начала и простота входа) и является определяющим фактором приоритетов выбора.

Ну все же есть и ещё одна причина — средняя скорость отклика по больнице. Мускуль несколько быстрее, особенно на интенсивных чтениях, MyISAM быстрее чем InnoDb, xtraDb, даже внутри самого мускуля, без Постгре… инмемори хранение… появилось в Постгре? не следил давно, ибо всё что попадается последнее время — проекты на Мускуле (Мария, Перкона..).

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

И это ещё одна причина предпочтения Мускулю: меньшие требования к ресурсам (дешевле сервер банально) для одних и тех же объемов и нагрузок. И кмк, совокупность (а не легкость начала и простота входа) и является определяющим фактором приоритетов выбора.

Выглядит, как совет «Сначала покатайся на вазовской классике, когда научишься, купи нормальную машину».

Порог входа для MySQL на порядок ниже.
Ну, мне конечно сложно оценить, потому что у меня не с нуля ни разу, но PostgreSQL я ставил именно ничего не зная о нем, скачал дистриб, распаковал, запустил, работает. Настройки потом конечно менять надо кое-какие, но у меня и ребенок это может сделать, если что (проверено). То есть, порог входа в PostgreSQL сегодня настолько низкий, что куда уже ниже и зачем — не очень понятно. И так легко все.

Выглядит, как совет «Сначала покатайся на вазовской классике, когда научишься, купи нормальную машину».

Порог входа для MySQL на порядок ниже.
Ну, мне конечно сложно оценить, потому что у меня не с нуля ни разу, но PostgreSQL я ставил именно ничего не зная о нем, скачал дистриб, распаковал, запустил, работает. Настройки потом конечно менять надо кое-какие, но у меня и ребенок это может сделать, если что (проверено). То есть, порог входа в PostgreSQL сегодня настолько низкий, что куда уже ниже и зачем — не очень понятно. И так легко все.

Есть ещё одна возможная причина. Порог входа для MySQL на порядок ниже. То есть он хорошо подходит для самого первого, «с нуля», знакомства. Правда, при условии, что в нём по максимуму отключены lamer-friendly расширения, и особенно — ONLY_FULL_GROUP_BY SQL Made. Иначе потом с него спрыгнуть будет тяжко.

Есть ещё одна возможная причина. Порог входа для MySQL на порядок ниже. То есть он хорошо подходит для самого первого, «с нуля», знакомства. Правда, при условии, что в нём по максимуму отключены lamer-friendly расширения, и особенно — ONLY_FULL_GROUP_BY SQL Made. Иначе потом с него спрыгнуть будет тяжко.

А можно в MySQL вообще писать расширения, и добавлять свои типы? В постгресе можно, и PostGIS тому пример.

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

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

А можно в MySQL вообще писать расширения, и добавлять свои типы? В постгресе можно, и PostGIS тому пример.

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

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

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

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

PostgreSQL поддерживает более широкий спектр современных типов данных, включая массивы, hstore (хранилище типа “ключ-значение”) и JSONB (бинарный JSON), которые обеспечивают более гибкие и эффективные возможности хранения данных. С другой стороны, MySQL имеет ограниченный набор типов данных и ориентирован на более простые веб-приложения.

PostgreSQL поддерживает более широкий спектр современных типов данных, включая массивы, hstore (хранилище типа “ключ-значение”) и JSONB (бинарный JSON), которые обеспечивают более гибкие и эффективные возможности хранения данных. С другой стороны, MySQL имеет ограниченный набор типов данных и ориентирован на более простые веб-приложения.

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

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

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

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