article

1 2 3 4 5

Re[22]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	18.03.10 11:25

Здравствуйте, Gaperton, Вы писали:

G>С формальной точки зрения — оба коммита относятся к одному тикету-фиче, обеспечивая его реализацию. value имеет тикет, а не коммит. И он должен служить поводом для коммита.

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

Тогда уже, если совсем формально всё делать, нужно поступать как-то так:

1. Кто-то завел тикет: «Нужно добавить такую-то функциональность»;
2. Разработчик разобрался в ситуации и создал еще один: «Нужно изменить то и сё в недрах программы», поставив первому тикету зависимость от второго;
3. Полез в недра программы, изменил то и сё. Одновременно закоммитил изменения в код и закрыл второй тикет;
(здесь можно ветку push туда, где код тестируется на предмет отсутствия регрессий)
4. Добавил такую-то функциональность, закрыл первый тикет.
(здесь уж точно push)

Будет совершенно четко видно, зачем делались изменения.

status=sent (delivered to file: /dev/null)

Re[23]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	18.03.10 11:34

Здравствуйте, Pzz, Вы писали:

Pzz>В этом есть свои плюсы и минусы. Плюсом является то, что пока я делаю свою фичу, я другим не мешаю. Минусом является то, что общий codebase меняется большими скачками. Люди будут с ужасом ждать моих коммитов в общую ветку.

Что здесь такого ужасного? Алгоритмы слияния нынче хорошие.

Pzz>Мы что-то не осилили посмотреть на базар, остановились на меркурии. Стоит базар того, чтобы на него дополнительно посмотреть?

Да все три хорошие, различаются только в деталях, вроде отслеживания переименований файлов (только bzr умеет), подхода к веткам (несколько директорий в bzr, одна в git), staging area (git), синхронизации удаленных веток (bzr умеет SFTP, хотя и тормозит при этом, git почему-то нет), поддержке ОС (git не очень дружит с Windows), GUI, плагинов, сообществ и т. д.

Если на чём-то уже остановились, то вряд ли будет много пользы от перехода.

status=sent (delivered to file: /dev/null)

Re[24]: Распределенный трекер

	От:	Clerk
	Дата:	18.03.10 12:47

Здравствуйте, Roman Odaisky, Вы писали:

RO>Да все три хорошие, различаются только в деталях, вроде отслеживания переименований файлов (только bzr умеет), подхода к веткам (несколько директорий в bzr, одна в git), staging area (git), синхронизации удаленных веток (bzr умеет SFTP, хотя и тормозит при этом, git почему-то нет), поддержке ОС (git не очень дружит с Windows), GUI, плагинов, сообществ и т. д.

Переименование файлов git тоже отслеживает:

[master b4f156a] test2
 1 files changed, 0 insertions(+), 0 deletions(-)
 rename test.cpp => test2.cpp (100%)

msysgit вроде неплохо работает под windows. Явных косяков пока не поймал.

... << RSDN@Home 1.2.0 alpha 4 rev. 1427>>

Re[24]: Распределенный трекер

	От:	Clerk
	Дата:	18.03.10 12:58

Здравствуйте, Roman Odaisky, Вы писали:

RO>Да все три хорошие, различаются только в деталях, вроде отслеживания переименований файлов (только bzr умеет), подхода к веткам (несколько директорий в bzr, одна в git), staging area (git), синхронизации удаленных веток (bzr умеет SFTP, хотя и тормозит при этом, git почему-то нет), поддержке ОС (git не очень дружит с Windows), GUI, плагинов, сообществ и т. д.

Подход к веткам — это которые branch? А что умеет делать с ними bzr такого, что не умеет делать git?

... << RSDN@Home 1.2.0 alpha 4 rev. 1427>>

Re[24]: Распределенный трекер

	От:	Pzz	http://pzz.livejournal.com/
	Дата:	18.03.10 13:13

Здравствуйте, Roman Odaisky, Вы писали:

Pzz>>В этом есть свои плюсы и минусы. Плюсом является то, что пока я делаю свою фичу, я другим не мешаю. Минусом является то, что общий codebase меняется большими скачками. Люди будут с ужасом ждать моих коммитов в общую ветку.

RO>Что здесь такого ужасного? Алгоритмы слияния нынче хорошие.

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

RO>Да все три хорошие, различаются только в деталях, вроде отслеживания переименований файлов (только bzr умеет),

А в чем содержательное отличие от hg mv?

Re[25]: Распределенный трекер

	От:	Clerk
	Дата:	18.03.10 13:24

Здравствуйте, Pzz, Вы писали:

RO>>Что здесь такого ужасного? Алгоритмы слияния нынче хорошие.
Pzz>Дело не в слияниях, а в том, что многие люди чувствуют себя неуютно, когда изменения приходят большими пачками.
Так ведь можно смотреть индивидуальные коммиты.

... << RSDN@Home 1.2.0 alpha 4 rev. 1427>>

Re[25]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	18.03.10 13:35
	Оценка:	4 (1)

Здравствуйте, Clerk, Вы писали:

C>Подход к веткам — это которые branch? А что умеет делать с ними bzr такого, что не умеет делать git?

Просто по-разному: в bzr разные ветки лежат в разных директориях, в git в одной. Подход git удобнее тем, что можно сначала работать с одной веткой, а потом добавлять еще, в то время как в bzr с самого начала нужно иметь иерархию вроде repository/trunk, даже если другие ветки пока не предвидятся. Подход bzr удобнее тем, что все ветки на виду.

status=sent (delivered to file: /dev/null)

Re[25]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	18.03.10 13:38

Здравствуйте, Clerk, Вы писали:

C>Переименование файлов git тоже отслеживает:

А директорий нет. Создай директорию «a» и положи в нее файл «f», в одной ветке переименуй ее в «b», а в другой положи туда файл «g». Слей всё вместе, получишь b/f... и a/g.

status=sent (delivered to file: /dev/null)

Re[25]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	18.03.10 13:56

Здравствуйте, Pzz, Вы писали:

RO>>Да все три хорошие, различаются только в деталях, вроде отслеживания переименований файлов (только bzr умеет),
Pzz>А в чем содержательное отличие от hg mv?

Mercurial не отслеживает директории. В эту ловушку: http://rsdn.ru/forum/tools/3741189.1.aspx, в отличие от git, hg не попался, но вообще неумение работать с директориями может быть проблемой.

status=sent (delivered to file: /dev/null)

Re[26]: Распределенный трекер

	От:	Clerk
	Дата:	18.03.10 14:08

Здравствуйте, Roman Odaisky, Вы писали:

RO>А директорий нет. Создай директорию «a» и положи в нее файл «f», в одной ветке переименуй ее в «b», а в другой положи туда файл «g». Слей всё вместе, получишь b/f... и a/g.
А разве это не логичное поведение? Ведь во второй ветке каталог "a" не был переименован.

... << RSDN@Home 1.2.0 alpha 4 rev. 1427>>

Re[27]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	18.03.10 14:23

Здравствуйте, Clerk, Вы писали:

RO>>А директорий нет. Создай директорию «a» и положи в нее файл «f», в одной ветке переименуй ее в «b», а в другой положи туда файл «g». Слей всё вместе, получишь b/f... и a/g.
C>А разве это не логичное поведение? Ведь во второй ветке каталог "a" не был переименован.

Нелогичное, конечно. Например, в одной ветке переименовали scripts.d в actions.d и соответственно изменили конфигурационные файлы, а во второй кто-то добавил еще один скрипт.

Файл же был добавлен не в директорию «a», а в контейнер 86f7e437faa5a7fce15d1ddcb9eaeaea377667b8, который на то время носил имя «a».

Ситуация не очень частая, но получается, что в git нельзя двигать директории туда-сюда, если есть хоть малейший шанс того, что кто-то в соседних ветках будет добавлять туда файлы.

status=sent (delivered to file: /dev/null)

Re[23]: Распределенный трекер

	От:	Gaperton	http://gaperton.livejournal.com
	Дата:	18.03.10 22:45

Здравствуйте, Roman Odaisky, Вы писали:

RO>Это чисто административный вопрос. Если потом разработчик полезет в историю выяснять, зачем сделан этот рефакторинг, и увидит ссылку на левый тикет, то будет введен в заблуждение.

Не будет он введен в заблуждение. Потому, что рефакторинг сделан в рамках работ по данному тикету. Если в комменте будет написано — "рефакторинг" — все все поймут.

RO>Будет совершенно четко видно, зачем делались изменения.

Можно, но совсем не обязательно. Объяснение в комментарии к коммиту, которое видно в трекере, ровным счетом ничем не хуже.

Re[23]: Распределенный трекер

	От:	Gaperton	http://gaperton.livejournal.com
	Дата:	18.03.10 22:51

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Gaperton, Вы писали:

G>>С формальной точки зрения — оба коммита относятся к одному тикету-фиче, обеспечивая его реализацию. value имеет тикет, а не коммит. И он должен служить поводом для коммита.

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

С точки жизненной практики работа по возведению стен как самостоятельная работа ценностью для пользователя не обладает. Ему надо все в комплексе. И эти детали, каким образом и в какие шаги вы решаете проблему — никому особо кроме вас не интересны. Делать несколько коммитов на задачу — это нормальная жизненная практика.

G>>Я тут подразобрался с bazaar, кстати. Они рекомендуют практику под названием feature branch. Она позволяет отразить множественный коммит в данном примере в нелинейной истории по человечески и без интеграции с трекером.

Pzz>В этом есть свои плюсы и минусы. Плюсом является то, что пока я делаю свою фичу, я другим не мешаю. Минусом является то, что общий codebase меняется большими скачками. Люди будут с ужасом ждать моих коммитов в общую ветку.

Не будут. Современные DVCS существенно лучше умеют сливать код, чем старые.

G>>Вообще, по совокупности и в итоге, для коммерческой разработки базаар из dvcs мне понравился больше всего (смотрел git, mercurial, bazaar). При этом, его я смотрел в последнюю очередь, и нехотя — буквально заставил себя. Потому что до этого решил, что остановлюсь на Mercurial.

Pzz>Мы что-то не осилили посмотреть на базар, остановились на меркурии. Стоит базар того, чтобы на него дополнительно посмотреть?

Обязательно. Я вот посмотрел на него, успев выбрать Mercurial — и был вынужден выкинуть Mercurial.

Bazaar прямым образом поддерживает workflow, важные не только для опенсорс, но именно для коммерческой разработке.

Re[24]: Распределенный трекер

	От:	Roman Odaisky
	Дата:	30.03.10 16:02

Здравствуйте, Gaperton, Вы писали:

G>Обязательно. Я вот посмотрел на него, успев выбрать Mercurial — и был вынужден выкинуть Mercurial.

G>Bazaar прямым образом поддерживает workflow, важные не только для опенсорс, но именно для коммерческой разработке.

А что именно bzr умеет, а hg нет?

status=sent (delivered to file: /dev/null)

Re[24]: Распределенный трекер

	От:	Cyberax
	Дата:	30.03.10 16:13

Здравствуйте, Gaperton, Вы писали:

Pzz>>Мы что-то не осилили посмотреть на базар, остановились на меркурии. Стоит базар того, чтобы на него дополнительно посмотреть?
G>Обязательно. Я вот посмотрел на него, успев выбрать Mercurial — и был вынужден выкинуть Mercurial.
G>Bazaar прямым образом поддерживает workflow, важные не только для опенсорс, но именно для коммерческой разработке.
Хм. А что конкретно он умеет такого?

Я просто на git'е сижу — и пока не могу найти то, что он не умеет

Sapienti sat!

Re[4]: Распределенный трекер

	От:	Aen Sidhe	Просто блог
	Дата:	06.04.10 09:50

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Gaperton, Вы писали:

G>>>>Волшебная фантастическая тулза. Как сказал рядом VGn — идея на миллион. Собственно, я давно уже подумываю о том, как бы такую штуку сделать. С описанным поведением масса концептуальных проблем, на самом деле.
C>>>Слушай, а давай займёмся? В принципе, могу на это выделить человека на месяца три-четыре.
G>>Заняться вполне можно было бы. Основная проблема — не в людях, а в том, что не до конца понятно, как к задаче подступиться.
C>Думается сделать очень просто — специальный каталог, в нём подкаталоги New, Assigned, Open, ... — по состоянию баги. На каждую багу делаем по одному файлу для удобства merge'а.

C>Обязательна синхронизация с Jira, естественно. Она становится одной из веток в репозитории.

И с TFS 2008/2010

С уважением, Анатолий Попов.
ICQ: 995-908

1 2 3 4 5