Недавно перенес свой сайт на хостинг за 24$ в год, в пакет включена поддержка svn (НЕ дополнительная услуга). Еще можно отдельно купить svn-хостинг, хотя существуют и бесплатные пакеты как например у www.xp-dev.com
Если svn не критичен, то можно использовать github.com (для git) или bitbucket.com (для mercurial)
То что вы описали — учитывается. Просто на диаграмме это не изображено. Диаграмма — самый сложный случай, когда все таки нужно поддерживать несколько версий. Банальный пример — open-source библиотеки и фреймворки. Например CakePHP работает как под PHP4, так и под PHP5 — нужно поддерживать обе версии. Плюс вышел PHP5.3 — вполне логично начать экспериментальную разработку с поддержкой новой версии. Итого — как минимум 3 параллельных ветки, ориентированных только на платформу. А ведь еще могут быть вариации самого фреймворка. Так что случаи с окончанием разработки в ветке версии после ее окончания — это не единственный случай, хотя и очень распространенный.
Не хотелось бы обсуждать диаграмму, так как я надеюсь что все таки доберусь до написания следующих статей где расскажу про всё это отдельно.
А что бы вы хотели чтобы было в подобного рода статье?
Между прочим, я рад что для вас всё изложенное просто и очевидно, так как, подозреваю, что не все могут этим похвастаться. Чтобы не оставлять вас абсолютно разочарованным после прочтения, предлагаю ознакомиться с диаграммой: bit.ly/34yQZx. Если у вас получится разобраться, и, более того, вндерить у себя в проекте, то я вас смогу искренне поздравить как состоявшегося scm-гуру. Эта диаграмма — конечный пункт моих попыток описать (это одновременно еще и содержание следующих статей) что такое scm и как можно улучшить существующее положение вещей.
1. www.ddengine.org/ — storage engine для MySQL, умеющий отслеживать изменения данных
2. Как уже сказал товарищ necromant2005, в RoR есть migrations
3. Если нужно migrations для php, то есть портированные: code.google.com/p/mysql-php-migrations/
Хорошо. Нашел я соответствующий раздел грамматики где говорится что это действительно допустимая форма возратного суффикса. Но еще там говорится что -ся — это редуцированная форма слова «себя». Так что употребление в том контексте, в котором вы употребили это слово, является семантически некорректным. А вообще, просто неприятно встречать «деревенские» слова, во-первых, в нехудожественном тексте, во-вторых, в совершенно неуместном контексте. Ведь и на иронию здесь намека тоже нет (не очевидно по-крайней мере).
и что ж это за орфография такая? можно ссылочку на соответсвующий раздел новой грамматики русского языка? всегда рад открывать для себя удивительные и парадоксальные вещи! может я действительно что-то пропустил…
Пока что не могу сказать конкретно, когда напишутся новые статьи. Дело в том, что не так просто уместить идеи из дипломной работы в нескольких статьях. К тому же еще не до конца продумана структура и формат будущего материала. Но желание поделиться наработками с сообществом довольно велико и это основной движимый фактор. Пока могу сказать одно — нужно чуть подождать. Спасибо вам за интерес.
ну в моем случае, как мне кажется, дела обстоят немного по-другому. есть набор деятельностей, которыми занимаются прогеры по ходу разработки. скилы по каждой из деятельностей вполне адекватны. но за счет того, что эти деятельности обычно проводились по отдельности, при их совместном использовании возникает куча проблем, так как они не приспособлены друг к другу. да и «менеджмент» и «конфигурационный менеджмент» — это довольно разные вещи. экстраполирование немного неуместно, хотя признаю — есть кое какие общие черты и недостатки.
Ну я ориентировался в основном на веб-приложения, которые мы разрабатываем/разрабатывали. Попытался как-то обобщить приобретенный опыт. Плюс брал во внимание стандартный набор деятельности, который я уже перечислял: контроль версий, сборки, юнит-тесты, статический анализ кода, генерация документации на основе исходного кода и непрерывная интеграция. По-моему, включение всего этого в область интересов метода конфигурационного менеджмента должно покрыть задачи, возникающие у довольно большого пласта типовых проектов. Предполагаю также что на твердом фундаменте формализованного метода можно построить и более сложный процесс, который учитывает больше нюансов.
Если svn не критичен, то можно использовать github.com (для git) или bitbucket.com (для mercurial)
Не хотелось бы обсуждать диаграмму, так как я надеюсь что все таки доберусь до написания следующих статей где расскажу про всё это отдельно.
Между прочим, я рад что для вас всё изложенное просто и очевидно, так как, подозреваю, что не все могут этим похвастаться. Чтобы не оставлять вас абсолютно разочарованным после прочтения, предлагаю ознакомиться с диаграммой: bit.ly/34yQZx. Если у вас получится разобраться, и, более того, вндерить у себя в проекте, то я вас смогу искренне поздравить как состоявшегося scm-гуру. Эта диаграмма — конечный пункт моих попыток описать (это одновременно еще и содержание следующих статей) что такое scm и как можно улучшить существующее положение вещей.
2. Как уже сказал товарищ necromant2005, в RoR есть migrations
3. Если нужно migrations для php, то есть портированные: code.google.com/p/mysql-php-migrations/
а вообще согласен. интеграция баз данных — это самое проблемное место.