Какую систему управления версиями вы используете (в реальной работе, больше всего)?

[DrLivesey]

Однажды довелось пользоваться Accurev, но проект кончился и начался проект где используется Git.

[amage]

От воспоминаний об AccuRev я покрылся холодным потом. Та же ситуация.

[DrLivesey]

Мда, та еще система. У нас еще и никакого толкового тренинга по ней не было. Все только с собственного опыта. При этом накопилось изрядное количество «НЕ ДЕЛАЙ ..., а то потом долго исправлять».

[immaculate]

Есть еще «замечательный» продукт IBM/Rational ClearCase. Люди платят $5000 за лицензию на одного человека, чтобы получить геморрой, после которого CVS кажется идеальным продуктом. Вот это настоящая загадка.

[Lavir_the_Whiolet]

Ответ к этой загадке прост: маркетинг. Почитайте статьи Даниэля Канемана.

[mark_ablov]

Только CVS, только хардкор!

[pcholberg]

Только FAT32, только хардкор!

[hedgehog]

FAT12 тогда уж

[zagayevskiy]

Проголосовало 430 человек. Воздержалось 59 человек.

Интересно, хоть 2009 (Проголосовало 2176 человек. Воздержалось 443 человека.) переплюнем? Если нет, то будет весьма и весьма грустно.

[Dm4k]

На самом деле прикольно наблюдать как из года в год перетекали пользователи SVN в Git. Жаль что из статистики выпали два предыдущих года.

[ashumkin]

переплюнули — 2500

[andy_p]

rcs

[ZoomLS]

В своё время понравился Subversion, но я тогда первый раз пользовался подобным. Сейчас везде Git.

[leschenko]

Git от TFS

[KvanTTT]

Лидер немного предсказуем.

[Acuna]

Все знали, что он всех порвет, это да. Просто лично я реально удивлен тем, какую долю занимает SVN. Нет, я знал, что небольшую, но чтобы настолько!

[sHaggY_caT]

Раньше был svn, теперь везде git

[MacIn]

Связка: SVN для репозитория и git локально.

[monah_tuk]

git-svn? А как мёржи делаете? externals? А то svn ветки так и мёржу самим svn.

И кстати да, как отмечать подобное? svn или git?

[Bozaro]

Есть возможность провернуть фарш в обратную сторону (репозиторий git, а локально — svn): github.com/bozaro/git-as-svn

Мы используем эту связку, чтобы использовать все плюшки git-а и дать части пользователей (не программистам) работать через svn-протокол.

[monah_tuk]

Не в нашем случае:

• в компании уже очень привыкли к централизованным VCS
• уже всё сделано на SVN
• многие заказчики для своих нужд тоже используют SVN

Но за наводку спасибо, положу себе в закладки.

[MacIn]

C SVNом работаю самим SVNом. Просто в локали можно быстро сделать новую ветку, прерваться, сделать другую задачу, затолкнуть ее в SVN и потом откатить в gitе локально. Все через diff2. У нас git не приживается — просто не нужна распределенка, а SVN приятнее на ощупь.

[immaculate]

Git/Mercurial в любом случае удобнее, когда над проектом работает более одного человека. Хотя я предпочитаю Mercurial. Но обе системы явно удобнее SVN, что для одного, что для нескольких человек. Просто по мере увеличения количества разработчиков преимущества проявляются все более явно.

[MacIn]

В каких-то командах — возможно. У нас — нет.

[Lavir_the_Whiolet]

Я вот хотел поставить Git, но самые передовые компании в Этой Стране используют SVN. :(

[QuickStudio]

«Эта страна» — Индия?

[questor]

— Мой код так прекрасен, что я хочу станцевать его.
— Петров, перестаньте паясничать на кодревью!

irony mode off

[QuickStudio]

Цитаты великих. Спасибо

[Lavir_the_Whiolet]

Нет, в Индии как раз сплошной Git-хайп. Я о России, конечно же.

[dron_k]

Наши коллеги в Индии без проблем работают с git

[beduin01]

Git, но я до сих пор готов заплатить денег если сделают что-то более простое и понятное.

[questor]

Вам надо посмотреть в сторону меркуриала, его обычно позиционируют так. Не пробовали или не подошло?

[ashumkin]

Вам сюда надо заглянуть :))))))))))

[JagaJaga]

Взгляните на pijul.org

[questor]

Больше всего TFS. Но мне кажется, что вполе вероятен переход на Git от TFS.

[leschenko]

От TFS как от ALM совсем не хочется уходить. А вот как от VCS без сожалений перешел на Git.

[FSA]

Как-то начал в своё время использовать Mercurial. Особо в нём не разбирался, просто была нужда иметь историю изменений и синхронизировать исходный код на несколькоих компьютерах. Недавно пытался использовать Git. Сразу же столкнулся с какой-то проблемолй синхронизации между компьютерами. Какое-то время поковырял. Потом решил, что овчинка выделки не стоит, тем более репозиторий пока не имел особо информации. Убрал Git и вернулся на Mercurial. Лучше кодом заниматься, чем разбираться в системах контроля версий. Да и экспертом в DVCS не очень то нужно мне становиться.

[kromxr]

Когда то давно сидели с коллегой и решили — пора уже нам попробовать что-то из систем контроля версий. (а нас было трое на проекте все новички по сути, и никто до этого не использовал контроля версий). Коллега был поклонником Ubuntu и предложил bazaar, ну а я каким-то интуитивным чувством был за git. В итоге я все же уговорил его перейти на git. C тех пор только git, хотя и были моменты когда приходилось работать с проектами на mercurial (более менее но много с чем так и не разобрался, а потом все равно все перевели на git), и на svn (буэ...., но git-svn меня спас)

[ProstoTyoma]

Ещё есть вариант Git внутри SVN. Очень приятно с легаси проектами получается.

[Bozaro]

А есть и SVN внутри Git: habrahabr.ru/company/mailru/blog/241095

[KvanTTT]

Интересная статистика. SVN с 2009 теряет позиции, а GIT — наоборот уверенно набирает. Жаль, правда, что 2013, 2014 года пропущены.

[vdasus]

Используем TFS, сейчас добился, что все приняли решение переехать на TFS + Git.

Для своих мелких задач использую bazaar как самый простой и логичный (для меня) в использовании. Знаю, что признаваться что тебе нравится bazaar это моветон и написан он ужасно и не развивается почти и его писал Путин лично, но… для совсем простых задач он намного проще в использовании чем Git. Гораздо меньше вариантов выстрелить себе в ногу. Для меня шоком было, когда узнал, что не всегда можно откатиться в Git на то, что уже положено в репозиторий.

Так что для простых задач, Hg или Bazaar, для серьёзной работы переезжаем на Git.

[PQR]

не всегда можно откатиться в Git на то, что уже положено в репозиторий.

а вот с этого места подробнее, пожалуйста

[vdasus]

The fundamental promise of any version control system is this: “Once you put your precious source code in here, it’s safe. You can make any changes you like, and you can always get it back”. Git breaks this promise. Several ways a committer can irrevocably destroy the contents of a repository:
1.git add. / … / git push -f origin master
2.git push origin +master
3.git rebase -i / git push
stevebennett.me/2012/02/24/10-things-i-hate-about-git/

Частично обходится, конечно, можно некоторые вещи закрыть через конфигурацию и т.п. Я ещё не настолько гуру-гит чтобы давать советы, просто как раз сейчас читаю массу информации о гите — уже промелькнуло мимо несколько «как я выстрелил себе в ногу»
Вчера вот, например, попалось: www.linux.org.ru/forum/general/10897902

[denver]

Для меня шоком было, когда узнал, что не всегда можно откатиться в Git на то, что уже положено в репозиторий

Several ways a committer can irrevocably destroy the contents of a repository:

Ага, можно даже грохнуть все ветки, надо же какой git небезопасный :)
Однако, дышите ровнее, git хранит локально все что удалено вышеуказанными способами. Вот пример куда копать:
dchekmarev.ru/blog/article/1313679957

[vdasus]

Спасибо за уточнение. Я ещё раз говорю, что пока не гит гуру. Просто много читаю на эту тему. Ссылок на «все пропало потому что» действительно попадается много. Понятно, что чтобы выстрелить в ногу надо «не дочитать, не додумать» и т.п. просто в некоторых системах такое невозможно в принципе. Т.е. если я положил что-то в базар или хг — я всегда, в любой ситуации могу восстановиться до этого состояния. С гитом есть варианты использования, где, конечно, «сам дурак», но данные могут быть потеряны. По крайней мере об этом много ссылок в интернете. Возможно такие гуру как вы и вытащите все что угодно со 100% гарантией.

Пара вопросов:
— То что вы написали как-то связано с комментарием по моей ссылке «По идее, если сборщик мусора еще не отработал»? Я ещё не углублялся в собрщика мусора, буду благодарен за то, что вы поделитесь опытом.
— Точно ли ситуация в описанном вами примере поможет в описанном случае? Некоторые моменты для меня пока не совсем ясны. Я боюсь спорить. Сейчас активно экспериментирую, читаю книги.
— Правда ли что положенные в гит файлы 100% *всегда* могут быть восстановлены?

Если что — я двумя руками за гит. Я его изучаю и мы на него переедем (это факт ибо идеологически он нам подходит), когда я буду готов к ответу на любые вопросы и к обучению джуниоров. Сейчас этап сбора информации и изучения.

[ashumkin]

Не denver, но тоже могу ответить

— То что вы написали как-то связано с комментарием по моей ссылке «По идее, если сборщик мусора еще не отработал»? Я ещё не углублялся в собрщика мусора, буду благодарен за то, что вы поделитесь опытом.

Да, в общем, связано. Чувак, делал git fetch (хоть и на bare репозитории), значит он уже получил весь репозиторий, просто перезатёр ветку (применив git push --force )
но автоматом сборщик запускается далеко не сразу

— Точно ли ситуация в описанном вами примере поможет в описанном случае? Некоторые моменты для меня пока не совсем ясны. Я боюсь спорить. Сейчас активно экспериментирую, читаю книги.

Не точно. Если бы он не делал git fetch , и не получал какие-либо уведомления c ID коммита, то есть вероятность, что тю-тю…
Однако же, него был исходный репозиторий в Hg, он имел репозиторий на двух машинах, так что почти невероятно…
но дай дураку… стеклянный…
(прежде, чем делать git push --force, надо понимать, что делаешь, а не выполнять бездумно «первый совет из гугла»)

— Правда ли что положенные в гит файлы 100% *всегда* могут быть восстановлены?

неправда, что ВСЕГДА 100%
то есть, почти такая же правда, как и восстановление удалённого на NTFS-разделе файла: при соблюдении некоторых условий

[tenzink]

Мы у себя запрещаем переписывание истории в репозитории на сервере. Права чтобы сделать `git push -f` есть только у избранных.

[denver]

Правда ли что положенные в гит файлы 100% *всегда* могут быть восстановлены?

Скажем, в 99.99% ;)

«Мусор» в git удаляется вручную запуском git gc, либо «автоматом вместе с некоторыми командами» (думаю очень специфичными), скорее всего *локально* он хранится очень долго и в git reflog можно найти все что было удалено/ребэйзнуто/аменднуто и т.п. Правда мне никогда не приходилось смотреть в reflog, если и делал push -f пару раз ошибочно то всегда находился коллега/сервер с актуальной версией. В остальном просто стараюсь делать копии веток которые собираюсь «портить».

[ashumkin]

git reflog --help — локально

на сервере тоже хранятся, даже если себе не fetch'или — если настроены уведомления, в которых рассылаются ID — это если по-быстрому…
медленее — git fsck

RTFM, в общем ;)

[vdasus]

Благодарю. А RTFM — обязательно. Без этого даже не начинаю

[vdasus]

парсер съел скобки, простите:
1.git add. / … / git push -f origin master
2.git push origin +master
3.git rebase -i <some commit that has already been pushed and worked from> / git push

[Lockal]

По состоянию на 4766 проголосовавших:

[Speakus]

Ещё есть 2014 год: https://habrahabr.ru/post/233935/
И кстати опрос содержащий два опроса по рабочим + своим проектам имхо более информативен.

[Propheta13]

На работе основные репозитории — SVN. Git + repo для некоторых частей.
На прошлой работе пользовали Git + Perforce.

[SabMakc]

В свое время отказывались от SourceSafe, выбирали между git и mercurial (изначально в списке был и bazaar, но почти сразу его вычеркнули, уже не помню почему).
Остановились на mercurial по нескольким соображениям:

1. Неизменность истории.
2. Простота.
3. Высокий уровень защиты от дурака.
4. Удобнейший GUI (TortoiseHG).

О выборе не жалели.

[PQR]

О выборе не жалели.

вы говорите в прошедшем времени… а сейчас что, в итоге пожалели?)

[ashumkin]

вероятно, SabMakc имел в виду «ни разу с тех пор не жалели» ;)