Много лет назад элегантно решил эту задачу следующим способом:
Есть основная «обычная» таблица foo(id, parent_id, label); на которой висит куча триггеров, которые уже «ведут» второстепенную таблицу foo_traversed(id, lft, rgt, level); таким образом никаких проблем с лочкой или непониманием со стороны нет. Запросы стандартных задачь делам либо через функции либо через LEFT JOIN
1) Ситуация исключена на организационном уровне. Клиентов готовят к тому, что их проект будет частью определённого релиза.
2) Релиз ветки, как явление, не содержат изменений вообще, только баг-фиксы. Все изменения в отдельных ветках, которые попадаю в trunk. Из него раз в месяц ответвляется новый релиз. Баг фиксы, соответственно, делаются только в релиз ветках (один раз) и пропагируют оттуда в trunk и другие ветки. Этим занимаются branch managers.
Вообще это стандартная практика. Release Driven Development.
притом из-за специфика SVN мы переносим все changesets как одну ревизию кода. все разработки ведутся не в trunk а в отдельных ветках, которые потом вливаниются в trunk перед тем как создаётся новая релиз ветка.
у нас trunk — это даже не продакшн, а просто основа кода. из него раз в месяц отделяем release branch который в течении месяца тестируется со всем сторон и потом она же попадает в продакшн; все новые разработки делаются в отдельных ветках, которые по завершению попадают в транк; таким образом минимальный срок тестирования любой новой фишки составляет 4 недели. стандартная release driven парадигма
> Надо отметить, что в SVN, конечно, есть ветки, но сделаны они, видимо, для другого, и поэтому плохо приспособлены для того, чтобы их сливать в trunk.
это вы какую-то фигню написали. вся суть репозитория — в ветках. всем разработчикам сидеть в транке — дурдом. к правилам создания веток хочу так же добавить ветки релизов, как без этого работать мне сложно понять. SVN прекрасно работает с ветками во всех направлениях, дайте мне кейс, кто она с ними не справляется как должно.
Я ничего не имею против оригинала; Просто получается что перевод изряда вон паршивый, ведь написано «всё-таки существующих 7359 МБ часто не хватает даже для базовых нужд.»
1. ограничение на размер письма было до недавнего времени 10 метров, сейчас 25. я этой фишкой всегда пользовался. предположим что в среднем нормальный человек это будет делать раз в месяц. сложив числа получаем 120 метров в год.
2. нормальные смертные этим не пользуются
3. задроты держат аккаунты на сервисах типа getdropbox где нет ограничений на размер файла
4. джедаи держат свои сервера :)
Есть основная «обычная» таблица foo(id, parent_id, label); на которой висит куча триггеров, которые уже «ведут» второстепенную таблицу foo_traversed(id, lft, rgt, level); таким образом никаких проблем с лочкой или непониманием со стороны нет. Запросы стандартных задачь делам либо через функции либо через LEFT JOIN
2) Релиз ветки, как явление, не содержат изменений вообще, только баг-фиксы. Все изменения в отдельных ветках, которые попадаю в trunk. Из него раз в месяц ответвляется новый релиз. Баг фиксы, соответственно, делаются только в релиз ветках (один раз) и пропагируют оттуда в trunk и другие ветки. Этим занимаются branch managers.
Вообще это стандартная практика. Release Driven Development.
0908 — это на продакшн сервере
0909 — в выходные будет go-live
0910 — это на следующий месяц, был ответвлён из trunk в эти выходные
по одному на каждый месяц. release maitainer каждое утро сливает все change setы — конфликтов за несколько лет работы практически не было.
выглядит это просто: утром запускается автоматические merges
0910->trunk->0909,0908
0909->trunk->0910,0908
0908->trunk->0909,0910
притом из-за специфика SVN мы переносим все changesets как одну ревизию кода. все разработки ведутся не в trunk а в отдельных ветках, которые потом вливаниются в trunk перед тем как создаётся новая релиз ветка.
это вы какую-то фигню написали. вся суть репозитория — в ветках. всем разработчикам сидеть в транке — дурдом. к правилам создания веток хочу так же добавить ветки релизов, как без этого работать мне сложно понять. SVN прекрасно работает с ветками во всех направлениях, дайте мне кейс, кто она с ними не справляется как должно.
в пользу GIT говорит только распределённость.
2. нормальные смертные этим не пользуются
3. задроты держат аккаунты на сервисах типа getdropbox где нет ограничений на размер файла
4. джедаи держат свои сервера :)
«You are currently using 1855 MB (25%) of your 7359 MB.»
Внимание вопрос — какие у человека могут быть _базовые_ нужды, чтобы использовать 7 гигов почты?
docs.php.net/manual/en/migration53.deprecated.php
и бац… вдруг всё перестаёт нормально работать. Как страшно жить!