Доброго времени суток!

Уже поднималась похожая тема, но меня интересует нечто другое, описаное в одном из постов к указанному выше топику. А именно:



Недавно начал успешно использовать систему контроля версий Subversion (на это меня натолкнула одна статья). Ощущение от использования трудно передать словами, был бы хвост - завилял бы  .
Мои подозрения о том, что система контроля версий не единственная "вкусность", используя котору можно облегчить себе жизнь оправдались. Об этом я прочитал в другой статье.

Предварительно (руководствуясь отзывами) остановил свой выбор на Trac.
Попытался поставить - ничего не вышло...
Ещё раз расспросил Googl'a. Посмотрел в сторону Bagzilla и Bonsai, окончательно запутался и понял, что я не смогу найти ответ пока точно не пойму, чего хочу.

А теперь непосредственно к вопросу.
Прошу рассказать, кто, чем и для чего пользуется и посоветовать, на чем монжно остановить выбор новичку исходя из следующих (предварительных) требований:
- программы должны быть бесплатны;
- системы будут использованы при написании программ с использованием C++, .NET, SQL(DDL). (Не web-приложения);
- OS Windows;
- командная (удаленная) работа не подразумевается, т.е. из расчета на то что "команда" состоит из одного человека иными словами для самостоятельно использвания (хотя, с другой стороны, возможно есть смысл "пощупать", что-то и для командной работы).

Буду признателен за любую помощь.

Смысл в багтреккере/тасктреккеров при работе в одиночку сомнителен. Только если работаешь над множеством огромных проектов и не в состоянии помнить о состоянии каждого  

Смысл в билд-системе? Да, есть конечно (хотя в CI и сетапе билд-сервера - это уже только в академических целях). Для .Net бы рекомендовал в первую очередь посмотреть на NAnt. С С++ подружить его вполне можно - само собой.

Полезным трюком будет также научить билд-систему прогонять тесты (модульные и функциональные) и пекеджить систему для деплоя (инсталлер).

Ну, к сожалению, множеством проектов и не пахнет  ... А за мнение спасибо. Т.е. багтреккер "в одиночку" - из пушки по воробьям?



Ну этот вопрос меня, собственно говоря, интересует в самую последнюю очередь... 



С тестами я только начал разбираться, но за рекомендацию опять-таки спасибо  ...

А
 
не приходилось пользоваться?

При линейной работе над проектом даже в небольшой команде зачастую прямая коммуникация (словесное описание тасков, багов и выяснение подробностей) может быть эффективней. А уж одному.. так и тем более.


Хм.. А зря. ИМХО билд-система - это первое, что нужно для организованной работы над проектом.


Ну.. doxygen-ом, конечно, пользовался. Но для .Net-а есть свои тулзы (встроенный генератор XML-документации, а дальше возможно NDoc, Sandcastle или даже собственная простая XSLT трансформация (в html)).

Хороший линк:  http://www.developers.org.ua/archives/jony...opment-process/    

Это сообщение отредактировал(а) NightmareZ - 9.8.2009, 20:44

To NightmareZ, 
спасибо, линк действительно хороший   ...

То Любитель, 
а какой багтрекер, стоило бы изучить (ознакомиться) с академической целью?

Ну.. С точки зрения базового использования все багтреккеры подобны. С точки зрения администрирования и каких-то особых фишек - конечно, надо изучать. Хотя.. тут проще просто работать с этим багтреккером - само освоится 

А так - для .Net-чика достаточно неплохо бы уметь админить тасктрекер из TFS, но к бесплатным это не относится. Из бесплатных, пожалуй Trac лучший. А вообще - я серьёзно, не стоит на это время тратить.. С настройкой - надо будет, разберёшься. А всякие мегафишки от багтрекеров - они программерам особо не нужны  

Любитель, 

учту... (но наверное немного Trac пободаю  ).

Ну и... раз уже начал, то добью  .
А приходилось ли пользоваться Wiki? Зачем ее используют? В качестве "доски объявлений"?

Gluttton, ты смотришь на средства, используемые при командной разработке. Wiki непосредственно для этого не предназначена, но часто используется. Как централизованный портал проектной документации, адресов серверов и пр. Не более того.

при изучении софта обращайте внимание на клиент-серверные приложения.
например VSS - НЕ клиент-серверное решение
SVN - клиент-серверное

это не про багтрэккер, а про систему хранения, но всё же.


(круглый)

To kolobok0, спасибо за совет. С системами контроля версий у меня всё ОК  . Уже почти год, как я открыл для себя Subversion и активно её использую...
Более того, раз заговорили о системах контроля версий, то, я слышал, что нужно отдавать предпочтение распределенным системам (например Mercurial).

Теперь непосредственно по теме...
Как я и планировал, пободался с Track'ом. Не хватило то ли терпения, то ли ума разобраться... Поискал аналоги. Нашел Redmine (статья), поставил, поэксперементировал и, согласившись с Любителем, пришел к выводу, что для людей не страдающих раздвоением личности польза от использования подобных систем сомнительна  .

Зато я, последовав совету Любителя, сосредоточился на использовании систем тестирования (NUnit под MS C#, пример). Пытаюсь "познакомиться" с Nant и CruiseControl.NET.



Это сообщение отредактировал(а) Gluttton - 28.8.2009, 21:40

по моему скромному мнению, 
вся идея в багтракерах в том, чтобы была полноценная связка:

т.е. чтобы была связь между коммитом, к номеру бага/таска, и из среды можно было видеть таски/баги, и фиксить их.
когда эта связка налажена нет практически никакого overhead-а над работой. в коммит пэйстится линк к тикету/таску, в студии/эклипсе/нетбинзе это отсвечивается.

в принципе вершен контроля конечно же хватит для начала.
но если смотреть стратегически:
а если у тебя появится тестер, или помощник ?
а если тебе придётся работать над несколькими проектами параллельно ?

если ты будешь работать в фирме, то думаю этот вопрос решат тебе 1-2 разовым инструктажом, поэтому не убивай время.
а если будешь работать самостоятельно, то думаю смысл это как раз имеет.

удачи.

bilbobagginz, спасибо за расширенное разъяснение!

P.S. Нашел для себя и рекомендую таким же как я (интересующихся) почитать это - достаточно сжато, доступно и в комплексе  ...

Да  фигня это. Современные системы контроля версий достаточно тупы и не развиты. Вот если бы можно было сравнивать изменение СТРУКТУРЫ и СЕМАНТИКИ/СМЫСЛА версий программы, то таки да. Было бы круто.
Я сейчас как раз над этим работаю.

Ведь не секрет что можно переколбасить весь исходник не изменив СМЫСЛА программы. Обычные системы контроля версий покажут море измененений в котором можно утонуть и заблудиться.

А потом, у некоторых глупых программистов в репозитории хранится до 1000 и более промежуточных версий. В которых они же сами начинают путаться.
И тогда система контроля версий уже не помогает в разработке, а вредит.

Успехов, как говорится. Особенно жду версии для C#. Пока пользуюсь классическими решениями, всё ж лучше, чем ничего. Но, например, даже просто автоматически находить те места, которые требуют refactoring'а, было б классно (да и прочий автоматический code review).