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

GIV>>>Где? Я как бы каждый день этим пользуюсь?
C>>Это что-то меняет в том, что история получается жутко нелинейной, особенно при множественных merge'ах?
GIV>Никак не пойму твоих проблем. Что такое нелинейная история?

Вот такая конструкция:

| commit1
| commit2
|---------------
|              |
| commit3      |
| commit4      commit_a
|              commit_b
|              |
|              |
|---------------
|
somecommit

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

S>Речь вообще-то шла только об одном из окон ankhsvn. Вот с ним — беда-беда, похожего для гита/hg в студии не попадалось.

Ты про какую студию? 2008? Потому что в более свежих давным давно такие окошки искаропки:
Ченджсет:

Дифф:


P.S. AnkhSVN — убогая подделка. VisualSVN намного лучше, хоть и небольших денег стоит.

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

GIV>Далее мерж этой ветки в мастер совершенно механическая операция.

Если бы.

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

IO>Эта интерграция какая-то малоюзабельная. Проще работать с гитом из Тортисы или вообще из консоли

Черепашка для гита безобразна, а из консоли диффы и дерево коммитов сложновато смотреть. Есть же нормальные клиенты — Git Extensions, SourceTree.

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

GIV>>Далее мерж этой ветки в мастер совершенно механическая операция.

AVK>Если бы.

А что за проблемы? reintegrate merge это тупое копирование одной ветки в другую. Вроде как конфликты там возникнуть не могут.

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

GIV>>Далее мерж этой ветки в мастер совершенно механическая операция.

AVK>Если бы.

Когда то давно, да все было грустно но последние несколько лет не помню проблем с этим.

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

BRA>К примеру вот дока по push:
BRA>git push
BRA>Имеется минимум познаний гита и требуется удалить ремоутный бранч. Найти для этого способ будет непросто, хотя операция должна быть элементарной.
Не понял. Вторая страница:

--delete

All listed refs are deleted from the remote repository. This is the same as prefixing all refs with a colon.

Здравствуйте, Sergey J. A., Вы писали:

SJA>А что за проблемы?

Конфликты иногда вылазят, хотя казалось бы.

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

GIV>Когда то давно, да все было грустно но последние несколько лет не помню проблем с этим.

С год назад в текущей версии проблемы точно были. С тех пор SVN почти не пользовался.

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

AVK>Ченджсет:
Так он не заточен под горизонтальный лэйаут, слишком высокий. А при вертикальном в список не влазит полный путь к файлу. Выглядит конечно симпатичнее, но по удобству мне нравится меньше.

AVK>Дифф:
И их я практически всех щупал, года два назад правда. Для быстрого диффа тортойзмерж вне конкуренции — он сразу при открытии схлопывает блоки без различий, не надо скроллить, чтобы увидеть все изменения.

AVK>P.S. AnkhSVN — убогая подделка. VisualSVN намного лучше, хоть и небольших денег стоит.
У меня ровно противоположные впечатления, но VisualSvn я в прошлый раз года три назад видел, могли и исправиться.

А вообще это всё спор про вкус фломастеров, всем разные нравятся

Здравствуйте, Нахлобуч, Вы писали:

Н>Здравствуйте, Abyx, Вы писали:
A>>проще — согласен, только откуда там больше возможностей?

Н>А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial?

А ещё в каждое обсуждение git'а обязательно приходит тролль, описывающий насколько mercurial мощней и удобней чем git

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

_>Сразу скажу — хотелось бы обойтись без священных войн.


Думаю, что проблема в том, что вы перешли на Git не потому, что почувствовали внутреннюю необходимость, а потому, что это "модно". И коллега вас, видимо "кинул". Раз он инициатор перехода, то и отвечать, и помогать остальным нужно ему.

Попробую описать несколько сценариев, когда git удобен. Если никогда не было внутренней потребности в сценариях такого типа, то git, bla-bla-bla ... вам не нужен

1. Я делаю изменение, которое естественно дробится на несколько логических частей
— Во время работы делается несколько локальных коммитов
— Пока не сделан push, я царь и бог: эти коммиты можно поменять (и даже удалить, поменять местами слить вместе, раздробить), если локальное тестирование нашло ошибку
— Перед push'ем ещё раз просматриваю коммиты, причёсываю (текст, мелочи) и делаю push

2. Я работаю над несколькими небольшими фичами / небольшими экспериментами / hotfix'ами в одной рабочей копии
— Делаю checkout фиче-ветки. Для небольших фич это почти мгновенно. Поработал, закоммитил. Отложил на время, или за-push'ил, если всё ok
— Переключился на основную ветку (или другую фиче-ветку)

Это 2 сценария, под которые git заточен блестяще. Основные идеи простые, и становятся понятными после прочтения вменяемого tutorial/книги.
Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.

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

К>Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.

Нет смысла изучать тонскости Git, если всё это есть в простом Mercurial.

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

К>Здравствуйте, Нахлобуч, Вы писали:

Н>>Здравствуйте, Abyx, Вы писали:
A>>>проще — согласен, только откуда там больше возможностей?

Н>>А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial?

К>А ещё в каждое обсуждение git'а обязательно приходит тролль, описывающий насколько mercurial мощней и удобней чем git

Mercurial не мощней (это технологии одного порядка мощности), а просто удобнее и проще. У Git много "ручек" и "кнопочек", как у пульта управления космическим кораблём на все случаи жизни, они даются в руки сразу и неосознанно тому, КТО будет ими пользоваться, с какими знаниями и способностями. Без чтения документации и досконального знания особенностей не обойтись. Результат: разрушение центрального репозитория при неосторожном применении ключа команды.

У Mercurial несколько простых запоминающихся команд, а под капотом есть эти самые "кнопочки" и "ручки", которые запрятаны, чтобы их только сознательно могли использовать, а не тыкать всё подряд, как это бывает с новичками. Результат: центральный репозиторий не может быть разрушен случайно.

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

AVK>>Ченджсет:
S>Так он не заточен под горизонтальный лэйаут

Это все принципиально меняет

AVK>>Дифф:
S>И их я практически всех щупал, года два назад правда.

Что значит "практически всех"? Это не "все", это родной студийный дифф.

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

ZEN>У Git много "ручек" и "кнопочек", как у пульта управления космическим кораблём на все случаи жизни

Бэкенд и должен таким быть. А простые и запоминающиеся должен фронтенд обеспечивать.

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

.>Во-вторых, что в общем-то можно сделать страшного? Запушить коммит удаления всего? Так первый же verify build зарежет. Засунуть в код бекдор? Ревьювер пошлёт. Разрешен прямой push? Ну git revert. Разрешен force push? И что, reflog 30 дней живёт. Сумели зачистить reflog? И что, gc вроде 7 дней loose commits держит. Ну ладно, в худшем случае, если все коллеги по проекту тоже сразу внезапно потеряли свои ноуты с клонами, либо в отпусках и не фетчат изменения, бэкапы забыли настроить, то как минимум останется история до последнего релизного тега, т.е. максимум потеряется изменения текущего спринта.

А как тебе сценарий с KDE?

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

N> А как тебе сценарий с KDE?
Над ними там уже поржали, почитай комменты.
В худшем случае, на компах разрабов бы остались бэкапы, можно было бы по частям восстановить. Что, конечно, сложно при таких объёмах данных, но возможно. В случае svn/etc потеря репо из-за проблем fs возможна так же, но восстановление истории было бы нереально, скорее всего.

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

К>>Нет смысла изучать что-то ещё (bisect, filter-branches, ...), пока нет потребности в соответствующем use-case'е.
ZEN>Нет смысла изучать тонскости Git, если всё это есть в простом Mercurial.

Нет смысла изучать тонкости ни Гита, ни Меркуриала, пока нет необходимости. При устоявшемся workflow обе системы простые, и задача людей, обеспечивающих миграцию, чтобы workflow был всем понятен.

Я пользовался обеими системами (VSS/StarTeam/SVN, потом Mercurial, потом Git), и Mercurial мне не кажется проще. Например, для DVCS удобная работа с ветками одно из главных преимуществ по сравнению с централизованными VCS. Я понимаю, как одной фразой описать, что такое ветка в git, но не понимаю, как это сделать в случае mercurial:
— в git — это указатель на позицию в графе коммитов. Это легко понять и рассказать.
— в mercurial — это что: clone, bookmark (похоже это аналог ветки git), named branch, ...?

В своё время наша компания переезжала на git, и я занимался переносом истории и консультацией коллег. Ожидалось, что первые несколько недель будут достаточно напряженными. На практике этого не случилось. Много вопросов было в первые пару дней, и сейчас возникают с периодичностью 1-2 раза в квартал.

Здравствуйте, dmitry_npi
Я использовал в продакшене и svn, и Git.
Вначале о svn.
есть клиенты для window, есть плагин для студии, есть клиенты и для других OS.
из минусов — постоянная необходимость наличия сервера, использование бранчей не очень удобное, так как опять же их нужно хранить на сервере.
в остальном все было ок.

Теперь немножко о git. Его в продакшене использую только пол года. Из плюсов — удобные бранчи, отвязаность от сервера.
Бранчи на самом деле даже мега-удобные, особенно если фича делается несколько дней. В конце можно взять все комиты, причесать и либо вмержить, лобо перенести в основную ветку как патч.
Gui так же есть — для windows есть TourtiseGit (его использовал только на личных проектах).
В продакшене использую SourceTree (OSX, Win), еще из годных знаю SmartGitHg. Из минусов для меня — пришлось поучиться этим пользоваться, workflow немного другой, но мне нравится больше. Опять же из минусов — на моем проекте работает с одним репозиторием порядка 15 человек, и как следствие иногда не успеваешь забрать все с сервера (pull), смержить со своими изменениями, как уже перед твоим комитом кто-то закомитил. Но такое у меня и на svn встречалось.

и как итог — я бы рекомендовал попробовать git на чем-нибудь простом, и если понравится — то пробовать переходить.
Как говорится лучшее враг хорошего.