LINUX.ORG.RU

Организация совместной разработки ПО на базе SVN+DocBook+Mantis: Часть 1

 , , ,


0

0

Эта статья открывает цикл материалов об организации совместной разработки программного обеспечения на базе SVN, DocBook и Mantis. В ней будет сделан обзор программного обеспечения и освещены некоторые вопросы. Материалы, изложенные в статье, будут интересны тем, кто занят в программных проектах, где задействовано более одного человека и требуется определенным образом увязывать результаты совместной работы в виде программного кода и документации. Проблема делится на две основные части: организация работы (следует сразу отметить, что без четкой организации работы использование любых самых удачных и прекрасных программных средств однозначно обречено на полный провал) и программная поддержка (речь не идет о средах программирования, CASE-средствах и прочем, что позволяет в результате получить программный код, скрипты, визуальные формы и т. д.).

>>> Подробности

★★★

Проверено: Shaman007 ()

Ответ на: комментарий от AnDoR

в дебиане все весьма опционально, так что не засчитано

anonymous ()
Ответ на: комментарий от anonymous

очередной анонимус, который не знает устройство дебиана?

хинт#2: debconf на перле, следовательно он там не опционален.

AnDoR ★★★★★ ()
Ответ на: комментарий от Zenom

значит, вы еще не познали дзен гита. читайте man gitworkflows

annulen ★★★★★ ()
Ответ на: комментарий от Zenom

>А для git уже появился аналог mq из коробки?

используй локальные бранчи и git rebase -i

annulen ★★★★★ ()
Ответ на: комментарий от anonymous

Ради redmine можно и руби поставить, про сырость не согласен, релизы давно уже стабильны. Все вопросы по плагину блога - автору плагина блога.

+1. Redmine вполне удобен.

В своё время было не удобно искать пользователей для привязки к проекту, но теперь это исправили.

То что вики очень простая напрягает, но терпимо.

З.Ы.: Redmine уже несколько лет используем на факультете, в основном для курсовых и квалификационных работ. Прикольно наблюдать когда же студенты пишут :)

Вт, 09 июня 2009, 05:35:33 +0400	...
Вт, 09 июня 2009, 05:14:54 +0400	...
Вт, 09 июня 2009, 03:39:50 +0400	...
Вт, 09 июня 2009, 02:01:33 +0400	...
Вт, 09 июня 2009, 00:15:20 +0400	...

AlexVR ★★★★★ ()
Ответ на: комментарий от AnDoR

уберите python из дебиана, отключите себя от интернета, заклейте окна и забейте гвоздями двери.

anonymous ()
Ответ на: комментарий от anonymous

>Trac зато архитектурно ущербен.

Для небольших проектов, особенно если не предполагается мощно администрировать трекер - самое то.

kraw ★★★★ ()

Тред не читал, сразу отвечал - сабж не нужен. TRAC же - интегрируется с любой SCM, надежен, функционален, на дебиане поднимается за полчаса, зависимости никакой.

anonymous ()

А в IBM используют Jira/Crucible для разработки своего ПО? Чтоже вы пишите про всякие Mantis и DocBook ?

gh0stwizard ★★★★★ ()
Ответ на: комментарий от AnDoR

>Т.е. ты предлагаешь решать проблему тормознутости и прожорливости жиры через ускорение веб-морды?

Вообще я имел в виду ещё и прожорливость жиры до оперативки.


Не знаю про какие тормоза речь. Jira летает в 1Гб спокойно. Не можете выделить столько ОЗУ - не юзайте Jira, она вам не по карману.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от anonymous

>статья ни о чем. перечислены вещи, очевидные для руководителя отдела разработки и ненужные для программистов.

из всех issue trackerов самый крутой - это jira. лицензия на 10 пользователей стоит $10, этого хватит для 80% читателей лора.


из виндоадмина в it - манагеры, из vb кодера в рук-ля отдела это всё странно.

dimon555 ★★★★★ ()
Ответ на: комментарий от gh0stwizard

> Не знаю про какие тормоза речь. Jira летает в 1Гб спокойно. Не можете выделить столько ОЗУ - не юзайте Jira, она вам не по карману.

На прошлой работе под одну жиру выделили отдельный сервер с quad-xeon и 4гб памяти. ворочалось оно там не очень

AnDoR ★★★★★ ()

Jira + Confluence. и SVN с Maven для разработки и сборок. Очень удобно и продуктивно.

WindowsXP ★★ ()
Ответ на: комментарий от annulen

> при правильной постановке работы с git/hg требуется часто пререключать бранчи. Если проект большой, скорость таких операций очень важна.

Это не правильная постановка работы. Читайте «Миф о многозадачности» и вникайте. Можете ограничиться пересказом.

PavelR ()
Ответ на: комментарий от annulen

>> Ты не только реактивный, но и шизоф^Wмногозадачный %)

одна фича - одна ветка

Это понятно. Если ты умеешь _постоянно_ работать над несколькими фичасми... ну ты понел %)

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

тогда hg-doxygen-moinmoin

А в роли багрекера что?

jira :)

shty ★★★★★ ()

голосую в этом треде за bazaar :-)

mkfifo ()

Очень похоже на спор «что лучше выпить - холодного кваса или горячего кофе?».

kraw ★★★★ ()
Ответ на: комментарий от anonymous

в интернете скачать можно и не платить. вы копираст?

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

anonymous ()

по-моему, дешевле купить джиру студию, чем тратить время на работу в таком убогом окружении.

JFreeM ★★★☆ ()

Я то думал, а оно то оказалось... :( Такое бодрое название и не менее бодрый анонс, а в самой статье - пшик с маслом. Хотя да, список оформлен превосходно.

Тем, кто тут хаит svn - вот скажите мне, нахрена бы использовать git или mercurial для какой-нибудь мелкой поделке на php/perl/python при числе разработчиков в 1-3? Получается у вас, что для разработки какого-нибудь генератора списка репозиториев для определенного дистрибутива нужно купить отдельный мощный сервер, поставить туда jira, в качестве системы контроля версий использовать git, mercurial или bazaar и разрабатывать все это в какой-нибудь IDE типа Eclipse или IDEA. Это даже не из пушки по воробьям, а использование ядерного оружия против тараканов.

alex-w ★★★★★ ()
Ответ на: комментарий от alex-w

>нахрена бы использовать git или mercurial для какой-нибудь мелкой поделке на php/perl/python при числе разработчиков в 1-3?

В такой ситуации, например, можно обойтись без выделенного сервера для репозиториев вообще. Как это сделать с SVN?

Zenom ★★★ ()
Ответ на: комментарий от yoghurt

> В оффлайне не закоммитишься в svn.

Сложность не для пользователей, в оффлайне и с git'ов не покачаешь. А так да, сферы применения различны.

Napilnik ★★★★★ ()
Ответ на: комментарий от annulen

>омг, для тебя vcs - качалка? открой возможность скачки тарболов из веб-интерфейсов репозиториев

А что же ещё)))))) К примеру захочу собрать новый mplayep, беру шпаргалку со всякими гитами и свээнами, качаю прямо из консоли и собираю (x264 только пропатчить надо, ошибку выдавал в этом году). И пофиг мне на ковыряние по броузеру, таким способом воспроизвести технологию проще и быстрее. Но когда на vcs лежит откровенно неполная версия, то да, приходится качать офсборку.

Napilnik ★★★★★ ()
Ответ на: комментарий от alex-w

>вот скажите мне, нахрена бы использовать git или mercurial для какой-нибудь мелкой поделке на php/perl/python при числе разработчиков в 1-3?

гит идеален для таких целей, а ide тут не причем.

annulen ★★★★★ ()
Ответ на: Re: вы ущербны от anonymous

Re: вы ущербны

Кстати, а где там плагины для получения odt или pdf из wiki ?

anonymous ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.