freepascal.ru

Padre_Mortius писал(а):И получим ситуацию, когда основной разработчик ушел и никто ничего не знает...
Я говорил даже не о создании ветвей, а банально о просмотре лога ревизий... Про комментарии у ревизий тоже никто даже не слышал...

1. Если не ведется документация, то без основного разработчика народ банально не будет знать для чего вообще проект (особенно в части разных нюансов). Никакой SVN или GIT здесь не помогут.
2. Лог ревизий можно смотреть когда угодно. Без необходимости чего на него глядеть?
3. Если нет плана действий, если нет трекера ошибок, то комментарии у ревизий будут в большинстве случаев бесполезны, т.к. редко когда коротко и лаконично можно написать что было сделано. И если для самого себя можно что-то кратко написать, а в 99% случаев другие не поймут про что речь.

Итого: VCS - это просто инструмент, сам по себе он мало что решает. Прозрачность разработки - это не самая простая задача. Если сама работа не упорядочена, то и никакой SVN ничем не поможет ее упорядочить. В подавляющем числе случаев на разработку влияют именно субъективные факторы, и формальный учет субъективизма очень сложен.

Добавлено спустя 4 минуты 34 секунды:
В дополнение. По факту VCS, если нет порядка в организации разработки (планирование, учет ошибок и т.п.), то они решают несколько более простых задач:
- резервная копия исходников
- обмен исходниками между разработчиками
- копирование исходников между компами (рабочий, домашний, ноут)
- фиксация конфликтов одновременной правки.
Не так уж и мало, но не следует ожидать большего, если не прилагать дополнительных усилий.

Vapaamies

Ohloh -- хороший писькомер, советую. Кто смысла в VCS не видит -- хоть померяемся.

https://www.ohloh.net/p/zcad

а с http://code.google.com/p/gource/ можно еще и мультики про процесс разработки посмотреть. Такчто от VCS одни плюсы))

Фактически я храню проекты на GitHub'е только для того чтобы в случае если накроется винт в компе, например, можно было их восстановить. Как резервные копии, короче
=========
1+.
Я также на GIT-е (развернул свой сервер в LAN) чтобы не таскать на флэшке между работой и домом, ну и иметь возможность откатиться если доизменял проект до маразма - просмотрев при этом полезные изменения.

alexey38 писал(а):В дополнение. По факту VCS, если нет порядка в организации разработки (планирование, учет ошибок и т.п.), то они решают несколько более простых задач:
- резервная копия исходников
- обмен исходниками между разработчиками
- копирование исходников между компами (рабочий, домашний, ноут)
- фиксация конфликтов одновременной правки.
Не так уж и мало, но не следует ожидать большего, если не прилагать дополнительных усилий.

Вообще то всегда рядом с VCS ставят баг-трекер и wiki и тогда мы получаем комплексное решения. К mercurial например цепляется redmine, а в моем любимом fossil все уже встроено.

Вы по-моему все отошли от темы пожелания. Репозиторий это банально удобно, меньше телодвижений надо, а вот уже нюансы работы с ним это другое. Как бы туда, что не вносили, это намного лучше чем просто голый исходник, где непонятно что сделано и когда.

Давайте все таки внесем это как правило для всех кто приносит свои проекты.

Kemper писал(а):Вообще то всегда рядом с VCS ставят баг-трекер и wiki и тогда мы получаем комплексное решения. К mercurial например цепляется redmine, а в моем любимом fossil все уже встроено.
Вы по-моему все отошли от темы пожелания. Репозиторий это банально удобно, меньше телодвижений надо, а вот уже нюансы работы с ним это другое. Как бы туда, что не вносили, это намного лучше чем просто голый исходник, где непонятно что сделано и когда.
Давайте все таки внесем это как правило для всех кто приносит свои проекты.

Для Open Source проектов VCS, баг-трекер и вики - это необходимость, скорее без этого будет не Open Source, а просто Source.

Тут попутно просто шло обсуждение, как и кто использует VCS. И я говорю, что в реальных проектах, если нет нормальной организации работ, то VCS - это просто удобное хранилищие, а баг-трекер и вики даже если и стоят, то мертвы или не актуальны. Именно организация работ и оргдисциплина заставляет всех участников использовать все эти инструменты. Банальный пример, чел получил замечания по телефону или по факту, исправил, а баг-трекере ничего не написал, коммент в VCS будет непонятным для других, все логи VCS стали бесполезными.

Пишите статью как этим хозяйством пользоваться.

Alek_Aaz писал(а):Пишите статью как этим хозяйством пользоваться.

Хммм.... А про какое конкретно? Вам чего централизованное или децентрализованное? Если централка смотри на SVN. Если децентрализованное уже называли. Информации огромное количество. Изучайте в интернете. Вам в любом случае учить придется.

Kemper писал(а):К mercurial например цепляется redmine

Редмайн и к свну цепляется не хуже) Очень хорошая вещь, только уж больно гемморная в установке.. По крайней мере под винду...

Причем, с проектом работаю только я один. Как не долбал сотрудников, пофиг веники. Никто даже не попытался создать репозиторий, хотя над проектом работаю 2-3 человека. И сервер им приготовил, и логины раздал...
Бардак!!!!!

Ну, в VCS еще въехать нужно. Лично я никак не возьму в толк GIT-ский "merging" & "branching" когда обнаруживаются кофликты версий, хотя приложил немало времени и усилий, чуть дым с головы не пошел. А то случайно сделаешь косяк, GIT начинает ругаться и фиг знает как вырулить. Разок не смог вырулить и пришлось персоздавать репозитрий на сервере. Поэтому пользуюсь GIT-ом как эдаким GoogleDrive (чтобы не таскать исходникин а флэшке) и страшно трясусь сделать что-нибудь не так. Поэтому понимаю ВАших сотрудников - они нуждаются в ликбезе и тренировках