>Но мы все должны быть зарегистрированы в одной и той же системе, так как между Basecamp никак не умеет общаться, скажем, с Мегапланом или Teamer-ом. Думаю, что этого не умеет ни одна система. Разве
что, допиленные специально для этого дорогие инструменты типа Джиры.
Это сложный функционал, со всеми обмениваться. Хотя со временем будет что-нибудь a-la Google Reader только для задач.
>Единственная фиксированная вещь, которая должна быть — папка (или что-то этого вида) с названием «Входящие», куда попадают все непросмотренные мной задачи.
Остальное дело вкуса. Можно так развить, а можно как-то иначе.
>Очень мало свободных и бесплатных систем.
Ну если redmine не устраивает, и пользователей больше 5-10 ( сейчас многие системы бесплатны на таком количестве пользователей), то, конечно, маловато.
Где-то с тысячи клиентов раз в две недели приходится чинить «битую» базу — «Internal gds software consistency check». Нужно заметить, что используется Firebird-1.5.5.4926, может, уже улучшили ситуацию. А может, и вообще это не с Firebird связано. Но вот такая ситуация имеет место быть.
> Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
Дык я ПРОБУЮ :). У меня коллега два дня уже убил на конвертацию базы svn->git, не конвертируется пока.
Ожидая результата мы решили поработать в SVN таким способом. Пробы удачны, ветки делаются а потом сливаются без особых проблем ( ясно, что это потому, что изменения простые). Но стало непонятно, а зачем так делать?
>Так проще потом отслеживать фиксы и фичи.
Про это нельзя ли подробнее, что это значит «отслеживать». Я «отслеживаю» в трекере, мне по сути все равно, какие там коммиты в репозитории. Главный критерий — все работает и тесты проходят.
>В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
Это вроде не конкретный пример, а лишь теоретическое соображение.
У меня задача в трекере связана с commitа-ми, если надо, я могу получить список коммитов, связанных с задачей. Но это пока не разу не требовалось, а мы выпустил почти сотню релизов только одного продукта. Что мы делаем не так?
Вот смысл делать ветку на каждую фичу мне не очень понятен.
>можно работать над несколькими фичами и фиксами одновременно
Да, иногда (редко) приходится все бросать и заниматься другой задачей. Тут да — делается ветка, туда сохраняется текущая работа и происходит переключение между задачами. В этом случае действительно, изредка делаются ветки.
Но зачем их каждый раз-то принудительно делать?
>Таким образом можно легко отслеживать добавленные фичи
Что конкретно имеется ввиду под «отслеживанием»? Интересно было бы рассмотреть конкретный пример из практики.
Вот у меня сейчас в сборке полторы сотни задач, они все лежат в трекере, я их там отслеживаю, из них четыре десятка я сгенерировал в процессе ручного тестирования новой сборки, типа тут подправить, там улучшить и т.д.
Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Коллега, а не поделитесь ли конкретными примерами, где используется частое легкое ветвление и слияние?
Рассмотрим типичные сценарии в одном из моих проектов. Характериcтики проекта — шесть разработчиков, SVN, Scrum, Test Driven Development.
В trunk у меня сейчас B84 ( следующая версия), B83 — в branches ( текущая версия, предрелизное состояние), B82, B81 — в tags.
Сценарий 1) Новая задача для B84. Разработка, unit-тесты проходят — commit в trunk. И так НЕСКОЛЬКО раз. Тесты и функциональность наращиваются постепенно, однако в любой момент времени тесты проходят.
Сценарий 2) Фикс для B83. Разработка, unit-тесты проходят — commit в branches\B83 + merge с trunk
Сценарий 3) Фикс для B82. Ветка в branches\B82.2, Разработка, unit-тесты проходят — commit в branches\B82.2 + merge с trunk и branches\B83
Сценарий типа (3) редок, и в 99% запускается только серьезных дефектов — мы выпускаем версию раз в 1-2 месяца, так что клиент в большинстве случаев может дождаться следующей версии (а раньше выпускали версию вообще раз в две недели, отсюда такие номерки).
Я тут пока не вижу необходимости использовать частое ветвление. Т.е. ветки делаются, но обычно по количеству релизов.
Если статья не сравнивает, тогда аргументация «Почему git» в терминах «основные плюсы» наверное не очень правильна. Плюсы — они же относительные.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
Я ведь сравниваю и рассуждаю на основе изложенного материала и опыта использования subversion. Да, переключение между ветвями и merge не такие гладкие, как хотелось бы, если в git что-то сделано гораздо лучше, хотелось бы знать, как и что именно.
Зачем нужна статья, которая не раскрывает преимуществ?
Я позволю себе сравнить с subversion, с моей точки зрения
2. Простые ветки в git позволяют в любое время достать версию любого предыдущего релиза и работать с ней не мешая идущей разработке. Исправить баги в отдельной ветке, смержить в предыдущий релиз и в текущую разработку.
Ну так и в subversion все так же
3. git хранит все свои данные в одном каталоге, а не плодит повсюду папки .svn. Переключить проект с одной ветки на другую можно всего одной командой или парой кликов в клиенте. При этом содержимое папки проекта заменяется новым, которое соответствует выбранной ветке..
Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.
Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.
4. Как я уже сказал, все комиты сохраняются локально и становятся частью общего репозитория только тогда, когда непосредственно пушатся в него. Это сложно вообразить, но порой получается так, что нет доступа в интернет, а работать нужно.
Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.
5. Удобные частичные комиты
Непосредственно перед комитом помечаются файлы, которые в него войдут с помощью git add. При этом существует возможность в отдельный комит внести часть изменений в файле, а не файл целиком.
В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.
6. Возможность припрятать изменения.
Пока не понял, зачем это нужно.
Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.
Сопротивление админов...
Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.
Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
Интересно, на хабре тоже будет тенденция с целью распространения контента прикручивать к нему все более и более откровенные фото моделей со все более длинными ногами :)
Потому, что Scrum (как и гибкая разработка (agile), да и бережливое производство (lean)) ориентирован на то, чтобы создавать законченный, готовый к поставке продукт! Ценность реализованной наполовину истории нулевая (а то и отрицательная). См. книгу “Managing the Design Factory” автора Donald Reinertsen или одну из книг авторов Mary Poppendieck и Tom Poppendieck.
что, допиленные специально для этого дорогие инструменты типа Джиры.
Это сложный функционал, со всеми обмениваться. Хотя со временем будет что-нибудь a-la Google Reader только для задач.
>Единственная фиксированная вещь, которая должна быть — папка (или что-то этого вида) с названием «Входящие», куда попадают все непросмотренные мной задачи.
Эх, у нас две папки, Входящие и Исходящие
Остальное дело вкуса. Можно так развить, а можно как-то иначе.
>Очень мало свободных и бесплатных систем.
Ну если redmine не устраивает, и пользователей больше 5-10 ( сейчас многие системы бесплатны на таком количестве пользователей), то, конечно, маловато.
Ну 1.5.5 это 2009-10-08.
Напишу в личку, thx
Дык я ПРОБУЮ :). У меня коллега два дня уже убил на конвертацию базы svn->git, не конвертируется пока.
Ожидая результата мы решили поработать в SVN таким способом. Пробы удачны, ветки делаются а потом сливаются без особых проблем ( ясно, что это потому, что изменения простые). Но стало непонятно, а зачем так делать?
>Так проще потом отслеживать фиксы и фичи.
Про это нельзя ли подробнее, что это значит «отслеживать». Я «отслеживаю» в трекере, мне по сути все равно, какие там коммиты в репозитории. Главный критерий — все работает и тесты проходят.
>В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
Это вроде не конкретный пример, а лишь теоретическое соображение.
У меня задача в трекере связана с commitа-ми, если надо, я могу получить список коммитов, связанных с задачей. Но это пока не разу не требовалось, а мы выпустил почти сотню релизов только одного продукта. Что мы делаем не так?
>можно работать над несколькими фичами и фиксами одновременно
Да, иногда (редко) приходится все бросать и заниматься другой задачей. Тут да — делается ветка, туда сохраняется текущая работа и происходит переключение между задачами. В этом случае действительно, изредка делаются ветки.
Но зачем их каждый раз-то принудительно делать?
>Таким образом можно легко отслеживать добавленные фичи
Что конкретно имеется ввиду под «отслеживанием»? Интересно было бы рассмотреть конкретный пример из практики.
Вот у меня сейчас в сборке полторы сотни задач, они все лежат в трекере, я их там отслеживаю, из них четыре десятка я сгенерировал в процессе ручного тестирования новой сборки, типа тут подправить, там улучшить и т.д.
Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Рассмотрим типичные сценарии в одном из моих проектов. Характериcтики проекта — шесть разработчиков, SVN, Scrum, Test Driven Development.
В trunk у меня сейчас B84 ( следующая версия), B83 — в branches ( текущая версия, предрелизное состояние), B82, B81 — в tags.
Сценарий 1) Новая задача для B84. Разработка, unit-тесты проходят — commit в trunk. И так НЕСКОЛЬКО раз. Тесты и функциональность наращиваются постепенно, однако в любой момент времени тесты проходят.
Сценарий 2) Фикс для B83. Разработка, unit-тесты проходят — commit в branches\B83 + merge с trunk
Сценарий 3) Фикс для B82. Ветка в branches\B82.2, Разработка, unit-тесты проходят — commit в branches\B82.2 + merge с trunk и branches\B83
Сценарий типа (3) редок, и в 99% запускается только серьезных дефектов — мы выпускаем версию раз в 1-2 месяца, так что клиент в большинстве случаев может дождаться следующей версии (а раньше выпускали версию вообще раз в две недели, отсюда такие номерки).
Я тут пока не вижу необходимости использовать частое ветвление. Т.е. ветки делаются, но обычно по количеству релизов.
Не поделитесь конкретными примерами? Типа вот такой сценарий, в svn все было бы плохо, а в git — все хорошо.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
Зачем нужна статья, которая не раскрывает преимуществ?
Ну так и в subversion все так же
Насчет папок .svn — не вижу тут большой проблемы. Лучше было бы без них, но мне они не мешают особо.
Про переключение — в subversion переключиться с ветки на ветку также легко, и содержимое аналогично заменяется. Возможно, тут есть ньюансы, и git переключает лучше, но этого я из текста статьи не понял.
Ну тут да, если нет интернета — ветку не создать. Пока мне лично не сильно мешало, однако, вещь полезная, безусловно плюс.
В subverion также помечаются нужные файлы, часть файла закоммитить… хм. Ну, не знаю.
Пока не понял, зачем это нужно.
Итого для себя один плюс — создание веток, когда нет интернета. Не густо, прямо скажем.
Ну, в таком раскладе, если админ обеспечивает «интернет», то его недоумение мне лично понятно — никаких других плюсов я лично пока не вижу.
Резюмируя — тема крупных преимуществ git (по сравнению с svn) не раскрыта, на мой взгляд. Однако, нутром чувствую, что-то у git есть. Возможно, там гораздо лучше реализован merge и переключение веток.
Sony a55
Может, кто-то развлекается таким образом. Вообще мне неясен смысл реагировать на спам способом сильно отличным от его удаления.
Такое противопоставление наводит на мысль, что движок хабра относится к категории хард :)
>Важно доводить решение задач до конца, т.к. выполненной можно считать только принятую заказчиком задачу
К примеру
Из Scrum и XP: заметки с передовой: