Pull to refresh

Comments 46

На втором рисунке все же граф, а не дерево.

А по делу: самого интересного тут и нет. Ну создал кучу веток, ну красиво их подписал — но это только вершина айсберга. В работе-то оно все как? Как мучаются разработчики с baseless-мерджами? Как конфликты разрешают рудиментарными ТФС-ными средствами?
Спасибо за совет,
Я попытаюсь дальше эту тему раскрыть, только начала писать…
Дальше напишу про права, политику и собственно и от лица разработчика сделаем код и попробуем его смерджить, черновик статьи сделал, в ближайшее время выложу, надо немного подредактировать.
И это в тот момент, когда всё прогрессивное человечество работает с git'ом, а отдельные ретрограды с hg.

Откуда вы это выкопали? Закопайте обратно.
Основной минус таких систем, как и SVN — это бесплатность. Они просто запрещены к использованию в большинстве корпораций, поэтому все реальное человечество работает на платных системах типа TFS и ClearCase, хотя я конечно же ничего против не имею против бесплатных систем, и даже за их использование, например, Тортила мне нравиться, вот только она у нас запрещена.
эээ, а что плохого в бесплатных системах? Не совсем понятно, честно говоря.
Ну скажем так, большим компаниям, типа Моторолы, Интел, Сименс и так далее, нужна нормальная сервисная поддержка по всему миру. Если что случиться с бесплатной системой контроля, например в подразделениями во Вьетнаме, к кому обращаться за помошью.
Именно поэтому в Мотороле, например, запрещено… да и у нас тоже.
очевидно к любому мейнтейнеру бесплатного проекта. в конце концов можете нанять вменяемого программиста, посадить его на пару месяцев в код «бесплатной системы контроля версий» и получите вменяемую поддержку по всему миру с гораздо большей отзывчивостью и меньшими затратами.
Там где нужно, моторолла нормально использует git & gerrit и не жужит. Инсайдерская информация, да :)
Оригинальная точка зрения о реальном человечестве…
Граф изменений по сравнению с DVCS страшен.
Запрещение к использованию SVN — совершенно непонятны причины.
И совсем непонятно, чем же провинились git, mercurial и bazaar…
Покажите пальцем компанию, где запрещено пользоваться SVN?
У нас за svn будут больно бить по голове учебником по git'у :)
немного кардинально, я бы не сказал, что нужно всегда использовать самое свежее и самое модное если инструменты покрывают нужды
Если человек лично свои файлы хранит в svn, то это его личные половые проблемы. У нас даже два человека в отделе разработки винды используют, хоть и стесняются этого.

Если же он хочет svn использовать для взаимодействия с другими сотрудниками — то бить git'ом по голове, пока не прозреет.
Да, что вы говорите, hg уже моветон, git единый нам озаряет путь :) И господи, они используют винду, я единственны сотрудник который использовал винду в офисе для разработки на PHP почему то не умер от стыда.
Видимо, мы находимся в разных мирах.

Кстати, что использует гугль у себя? А facebook? А redhat? Неужели платные системы?

Или вы про старые сдыхающие конторы типа Axapa и Navision, которые ждут-недождутся, пока их кто-нибудь не купит?
Я не знаю, что использует Гугль, думаю, что они используют свои системы, которые сами и написали, также наверняка поступает и Microsoft…

Точно знаю, что Моторола, да и вообще многие американские конторы используют ClearCase.
Майкрософт — разумеется. Эти чудики даже сайты на IIS держат, вместо haproxy.

А вот насчёт facebook/google — позвольте не согласиться. Тот же flashcache опубликован именно на гитхабе — видимо, потому что у людей был гит (врят ли они его конвертили для публикации, проще было бы просто тарбол выложить).
Возможно, но опять же я не утверждаю что все компании :) Многие, возможно большинство, на этом построено и их развитие.
Сделал один раз, у тебя купили, купили поддержку, и платят каждый год, за то, чтобы у проблем не было, а возможно за 10 лет ничего и не случиться.
Это как страховка… купил, а в аварию не попал.
А ты на эти деньги живешь, обновляешь, всякие фичи каждые два года выпускаешь, все нормально, все довольны :)
Вы всё это так говорите, как будто предлагаемые решения лучше гита. Лично я могу сказать, что багтрекер у нас в конторе проприентарный. Потому что другие «не пошли».

А вот гит — извините, never knows best. Основной же вопрос не что юзает контора, у которой бухгалтерия с 1975 на коболе написана, а что использовать. И ставить какое-то левое проприентарное дерьмо вместо адекватной распределённой vcs — это бред. Особенно в 2011.
Нет, я не говорю, что это решение лучше, я лишь хочу показать, что оно простое в использовании, свои задачи решает, и имеет свои плюсы, как впрочем и минусы.
Идеальной системы нет и не будет.
В принципе меня устраивал и ClearCase, но просто не дружит IBM с Microsoft, отсюда, куча проблем была с обоими…
Оно проще гита? Извините, мы, видимо, мыслим разными категориями. Убогая графическая поделка, в которой не работает ничего из coreutils не может быть проще, чем шелловая. Потому что если мне какой-то функции в гите не хватает, она появляется простым pipe в другие утилиты. А в вашем случае что делать?

Допустим, мне нужно посмотреть все коммиты, которые были между коммитами aaaaaaa и bbbbbbb, в которых был затронут файл foobar.c, авторства Foo J. Bar и с словом baz в описании.

Ваше решение?
Он возможно и не проще, потому что я не спец по гиту.
В данном случае, если я вас правильно понял, то это можно сделать двумя путями в TFS, по нашему процессу.
1. Встать на ветку разработчика Foo J. Bar, нажать на файл foobar.c, и получить весь список changesetов. Берем чендсеты с аааа и смотрим до вввв… см картинку, там поле юзер скрыто… буква S. (это я он же lamerok), потому что к сожалению пользователя Foo J. Bar нету.
2. Тоже самое только с метками
Единственно проблема с описание, хотя оно есть, но фильтра по нему нет, хотя можно и отсорторовать. Но опять, же все зависит от того, как у вас построен процесс, вы его строите, так, чтобы не возникало желаний делать такие запросы :) Но это ИМХО.
image

Нету «ветки разработчика». Есть общее дерево коммитов, среди которых есть коммиты человека.

А «единственная проблема» — это то, про что я говорю. Все эти гуёвые перделки тут же сливаются, как только речь заходит о «нам бы тут подобие grep, awk и ещё чуть-чуть sed».
Гугл вроде использует perforce, платную, 740$ за пользователя. Вместе с ними ее используют JetBrains, HP, Samsung, HTC, Cisco, nVidia, Blizzard, Sony, да дофига, кто еще.

На самом деле, большие репозитории гит (а возможно и другие DVCS) так себе обрабатывает. Под большими имеются в виду размером в несколько гигабайт. А на относительно небольших проектах он более чем удобен.
Ядро линукса — достаточно большой проект?
Репозиторий ядра линукса занимает вроде порядка 300М, а после вызова git-prune вообще до сотни ужимается — так что не очень большой (я там выше про гигабайты писал).
Ну, я не думаю, что есть отдельные репозитории существенно большего размера.
Да ладно. В репо ядра линукса только исходники, т.е. текстовые файлы, хорошо жмущиеся zip'ом.

Графических ресурсов там, например, нет. Зависимостей в бинарных файлах — тоже. У меня сейчас пруненый репо занимает полсотни метров (всего в два раза меньше ядра линукс, ага), при том, что я его разрабатываю существенно меньше по времени и существенно меньшим количеством человек — так что я вполне могу представить проект с репо в несколько гигов.

Да, про плюсы гита я в курсе, сам его использую, и в большинстве случаев это VCS №1. Но в то же время, я представляю себе его недостатки, и ситуации, когда его применять не стоит.
GPL не запрещает продавать программы. Вы купите у меня git, скажем, за 1000$? Тогда он уже перестанет быть для вас бесплатной системой и вы, наконец, сможете им пользоваться.
Крупные Корпорации не используют Нищебродский Софт по $1k за копию. Крупные Корпорации используют только ПО с лицензированием от $30k за первый год и от $20k за каждый последующий, умножающийся на 4% в год (инфляция) за каждое ядро и каждые 4Гб используемой памяти?
Все верно… так и выходит. Из-за одного антивируса всем компьютеры поменяли на XEONы. Трудно понять логику Крупных корпораций, но скорее всего, она заключается в том, что лучше заплатить побольше денег и потом иметь меньше гемора и хорошую поддержку.
Только так могу объяснить…
Для малых и средних, все верно — хорошие, проверенные временем бесплатные системы.
Вопрос про vcs у гугля и фейсбука вы проигнорировали или не заметили?
Автор действительно только «прошелся по верхам». Самого интересного не поведал :)
У меня есть более года плотного общения с TFS 2010 (установка, администрирование, поддержка команд разработки в плане TFS, трекинг багов/тасков, континиус-интегэйшин и прочее). У TFS есть плюсы, есть и минусы. Если у вас есть вопросы, задавайте, попробую ответить.
мы работаем с TFS 2010 больше года. До этого я работал с SVN Tortoise — земля и небо. Жаль, что TFS платный, юзал бы его в домашних условиях.

1. Если я начинаю изменять файл, то получаю новую версию. Если файл уже был кем-то изменён, пока я «чесался», то TFS скачает прежде новую версию, чем даст мне возможность править. Так я избегаю большую часть серьезных конфликтов при дальнейшем мердже. Своеобразный Lazy Load. И это всё помимо регулярного получения последних версий и коммитов. При этом нет такого, что если кто-то залил свои изменения, то все они прилетели ко всем остальным разработчикам и проекты перестают собираться у всех.

2. Обычные конфликты в 90% случаев разрешается сами. Если нужно что-то подправить, то WinMerge подсвечивает лучше стандартного Tfs редактора. Но и тот отлично справляется.

3. Contineus Integeration сразу присылает сообщение на мыло разрабу, если он, нерадивый, залил код, который не собирается или падают тесты. Сообщения и билды весьма гибко настраиваются. Можно даже запретить заливать новый код, если тесты не проходят.

4. TFS ещё и рулит тасками и багами. Таски назначает лидре или разраб. Баги через таск-систему назначает тестировщик. Можно выполнить, вернуть, отказаться, перенаправить на другого, разделить на подзадачи (ветвление дерева), проставить различные статусы, комментарии с датой и временем, прикрепить файлы (например доки или дамп базы). Менеджеры по таскам строят свои графики проекта (их там очень-очень много)

5. Каждый коммит можно (а у нас и нужно) прикреплять к отдельному таску. Так видно какая задача какие изменения вызвала. И какие коммиты были привязаны к той или иной задаче. А не искать всё только по комментариям.

6. Всегда можно посмотреть историю коммитов. Кто какие файлы заливал, что менял. Сравнить любую версию файла с любой версией того же файла (хоть более новой, хоть более старой)

7. Можно «зашелвить» задачу — «положить изменения на полку», т.е. создать отдельную «ветку» только для своих локальных изменений и расшаривать их между несколькими разрабами не заливая все изменения в основную ветку. Таким образом не нужно больше плодить кучи веток. У нас их, например 2: для тестировщиков (более стабильная) и для разработчиков. Работает человек 40-50 всего. Проблемы с упавшими билдами возникали раза 2-3 в неделю(когда было можно заливать такой код), но решались быстро. ДА и всегда можно откатиться на предыдущую версию.

PS на одной конференции рассказывал некий git — евангелист как круто работать с гитом и гитхабом. Слушая его сравнивал с TFS. Помню, что по ощущениям я бы не стал менять систему контроля версий на git. Не знаю, может быть там и есть всё, что я здесь описал для TFS, но он об этом не рассказал.

8. Все файлы хранятся на компе. скачиваются 1 раз и потом изменённые только перезаписываются.
Все, кроме 1, прекрасно работает в меркуриале. Бесплатно, быстро, не требуя связи с центром.
1. Не его собачье дело, что и в какой версии я буду менять.

2. Не есть достижение TFS; в современных VCS'ах все именно так. WinMerge хорош, но это не TFS, встроенные средства которого — обнять и плакать.

3. CI это хорошо, но там типичный Enterprise Bloatware. И как, позвольте узнать, будете тесты исправлять, если запретите новый код коммитить?

4, 5. Не бином Ньютона.

6, 7. Об этом упоминать вообще стыдно.
1. Все еще забавнее — если он мне скачает только 1 файл, а не сделает update всей рабочей копии, то у меня в 99% случаев будет что-то сломано и хорошо, если только сборка.
и это есть правильно, т.к. после этого придётся скачать все остальные модули, зависимые от данного файла. Как правило, это 1 сборка.
А иначе, если вы будете менять уже неактуальную старую версию, добавлять в неё свою логику, то когда вы начнёте её мержить, то врагу больше такого не пожелаете.

Это не есть правильно, потому что в нормальных VCS версию имеет не файл, а репозитарий, что абсолютно логично для исходных тесктов программ, автоматически обеспечивая их согласованность между собой.
Т.е. вместо того, чтобы спокойно сделать update рабочей копии и получить новую версию или не делать update, взяв merge на себя, мне автоматически ломают рабочую копию, обновить которую до согласованного состояния я должен уже руками?
TFS-ом пользуемся уже более 2 лет. Готов согласится практически со всем. Действительно удобная система. Хотя и не лишенная некоторых недостатков. Как всегда от крупных вендоров, чтобы насладиться всеми плюшками приходится вкладываться в дополнительное ПО.
Так, если хочешь полноценную систему отчетов, то будь добр раззорись на нормальный SQL сервер с поддержкой репортинга (можно поставить на бесплатный SQL Express, но отчетам — гуд бай). Тоже самое и с SharePoint, можно поставить на бесплатный Foundation (и потерять часть функционала), а можно на SharePoint Server и получить парочку дополнительных вкусностей.
Чем эта система удобнее того же меркуриала?
Я Mercutial не пользовался, но судя по информации на сайте, это система контроля версий. TFS — это система управления проектами. Т.е. система контроля версий и плюс много всего того, что позволяет сделать разработку проще. Классический сценарий. Нарисовали в Visual Studio диаграмму Use Case (UML). К каждому прецеденту добавили Product Backlog Item. Затем разбили его на Tasks, которые запланировали по времени. Разработчик берет задачу, решает, делает комит. Как только все задачи решены и функционал проверен, Product Backlog Item закрывается. Все эти активности можно отслеживать. Причем когда человек начинает работать по задаче, он может пройти по всем этим деревьям до диаграмм и выяснить глобальные вещи. TeamLead может в обратную сторону проверить открыть диаграмму и идя вниз по дереву посмотреть, как идут работы по каждой UserStory. Ну и много всего еще.
Ставим бесплатный redmine — имеем все то же самое, кроме фазы с UML (интеграция с мерком там из коробки).
Итак — есть интеграция с UML. Что еще?
Еще раз, мне сложно судить, не имея опыта работы с системами, которые вы упоминаете. Я допускаю, что все то, что есть в платном TFS, есть в бесплатных версиях от других разработчиков. И это просто замечательно.
Мы используем TFS в связи с тем, что у нас разработка ведется на Silverlight или WPF. Я знаю только одну версию инструментальной среды разработки, которая поддерживает эти технологии в полном объеме, на уровне последнего framework. Это Visual Studio 2010. А дальше все просто. Единственный программный продукт, который обеспечивает поддержку всего цикла разработки от проектирования, до тестирования и развертывания, это TFS. Поэтому мне некуда деваться с подводной лодки. Если есть возможность получить все то, что мне дает связка VS 2010 + TFS 2010 в другой компоновке, то я бы с удовольствием такой вариант рассмотрел. Но! VS 2010 пока является обязательным условием. Поэтому, если знаете, где можно почитать о том, как интегрировать VS 2010 + <продукт нейм>, чтобы все работы архитектор, проектировщик баз данных, программист, тестировщик, специалист по развертыванию, делали в VS и все это адекватно сохранялось в <продукт нейм>, отпишитесь здесь, или на почту.
Спасибо за полный ответ. Нужной глубины интеграции со студией у сторонних бесплатных продуктов, естественно, нет и это реально киллер-фича.
вот же поведение школоты на хабре.
называется — «Поделись своим опытом и получи минус в карму от очередного обиженного жизнью евангелиста»
Мне кармы не жалко, но грустно смотреть на таких.
Sign up to leave a comment.

Articles