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

SVZ>>Поясню для ТС: Stash — средство для хранения "недоделок". Когда нужно срочно отвлечься от текущей задачи, что-то быстренько закоммитить, а потом вернуться к своим делам.

S>Не в порядке спора

S>В SVN для этого просто используются выборочные коммиты. Ну или changelists, если файлов много. Это чисто локальная штука, представляет из себя просто список файлов. В UI файлы отображаются группами (как пример — нижний скриншот вот тут). При коммите выбираем только нужные changelist, коммитим.

Я, кстати, никогда этой функцией не пользовался. Сейчас почитал твою статью, Stash это немного другое.

"ignore-on-commit" не дает закоммитить файл по ошибке. А Stash позволяет запомнить текущие правки, затем откатиться к исходной версии, внести в нее другие изменения, их закоммитить, а потом продолжить прерванную работу. И всё это без переключения между ветками.

Тут рядом Хон-Гиль-Дон верно сравнил его с локальными ветками. По сути то же самое, только ветку создавать не надо, этакий "синтаксический сахар".
Когда задачи небольшие, скажем, на день, то лениво выделять под задачу отдельную ветку. Хотя это вопрос организации работы.

S>Для более-менее долгих задач удобней всё-таки полноценные ветки, тут dvcs побеждают с диким отрывом
S>Справедливости ради, в svn свитч с ветки на ветку не так быстр, как в git, но тоже терпимо. От полуминуты на мелком проекте до 10-15 минут на гигабайтах исходников (это вместе с поиском ветки в repository browser, он в tortoiseSvn знатно тупит).

Это верно, особенно на разлапистых проектах с большим числом веток. У Тортиллы еще неудобно, что многие операции делаются Drag-n-drop'ом на дереве. Очень легко промахнуться.

_> Вообще-то при сравнении централизованной системы (Subversion) и распределенной системы (Git), все с точностью до наоборот — если недоступен репозиторий централизованной системы, то ... ничего и не получится. А в распределенной системе программист, как правило, использует локальный клон удаленного репозитория, и спокойно с ним работает (просматривает историю, фиксирует изменения ит.п.). И по мере необходимости синхронизирует его с удаленным репозиторием.

Я как бы в курсе про DCVS, приходится работать.
Ага только централизованная система у себя в серверной в прямой доступности, а распределенная на битбакете, появляется дополнительный канал Офис <-> репа, а его наличие и работоспособность зависит от провайдера и следующего аплинка(ов). Первоначально речь шла о билд сервере который делает сборки и ему надо обязательно выгребать изменения. Для разработчиков временная недоступность относительно безразлична.

S>* Простая работа с ветками, но ровно для одного сценария: отрезали ветку, периодически забираем исправления из транка, затем сливаем свои исправления в транк. Шаг вправо-влево — лучше не пробовать.

Обычно несколько разная схема работы с ветками.
В свн каждая ветка в локальном репозитории лежит в отдельной папке.
В гите — все в одной папке.
Может занимать много места, и в гите можно переключаться, не закрывая студии.

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

T>Ага только централизованная система у себя в серверной в прямой доступности, а распределенная на битбакете, появляется дополнительный канал Офис <-> репа, а его наличие и работоспособность зависит от провайдера и следующего аплинка(ов). Первоначально речь шла о билд сервере который делает сборки и ему надо обязательно выгребать изменения. Для разработчиков временная недоступность относительно безразлична.

Вах, а что, гит не ставится на локальном сервере?

ХГД>1) Скорость — git быстрее минимум на порядок. Правда, с SVN я сбежал уже давно (лет пять назад), может сейчас SVN менее тормозной, не знаю.

Если сеть быстрая, то всё вполне терпимо.
Чисто локальные операции, такие как svn st/git status сравнимы. На больших репозиториях SVN (у меня) отрабатывает быстрее.

А вот svn checkout/git clone — тут git просто в клочья рвёт svn.

ХГД>2) Ветки. В SVN пять лет назад работать с ними было практически невозможно, в git — просто и естественно.
Сейчас вполне возможно, но в git-е проще и удобнее.

ХГД>3) В git возможен коммит не всего файла, а частей.
В svn Такого нет, но TortoiseSVN позволяет (Restore after commit).
И если мои подозрения верны, и GIT позволяет включать/выключать только на уровне кусков изменений(hunk-ов), то в TortoiseSVN это даже удобнее.

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

_>Пишем в Visual Studio. Там есть плагин для гита.

Для начала: существует TFS, и для ВижуалСтудии он подходит идеально. Всякого рода гиты с эсвээнами для студии все же чужеродны.

_>Децентрализация. А зачем она?

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

_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https.

https существует не только для защиты пароля. Ключ SSH для SSH используется, как клиентский сертификат в SSL

_>ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ.

Не надо. Ключи SSH вообще шифровать необязательно.

_>https, а можно по ssh. Я вообще раньше думал, что это одно и то же...

Боже мой. facepalm.jpg

_>чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.

Для меня в гите есть такая удобная вещь, как stash. Можно засунуть туда локальные изменения для большой и долгой работы, быстренько сделать срочную работу — баги поправить, достать изменения из stash обратно и продолжить.

По сравнению с TFS у гита преимуществ я не вижу. А, еще ключ ssh можно на токен записать и ходить с ним, нет ключа — чужой не подключится. Это удобно, когда на основной работе занимаешься другими проектами.

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

Q>В свн каждая ветка в локальном репозитории лежит в отдельной папке.
Эмм, в svn вообще нет локальных репозиториев
Можно держать несколько Working Copy — по одной для каждой ветки, можно переключать одну и ту же Working Copy между разными ветками.

Q>Может занимать много места, и в гите можно переключаться, не закрывая студии.
Ну... .svn-репы обычно компактнее за счёт того, что история не хранится локально. На сервере — да, git эффективней в 2..5 раз, но кого это волнует?

Svn тоже не требует закрытия студии для свитча, AnkhSvn -> switch solution. Но по времени с гитом не сравнится конечно.

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

_>Моя работа — написание программ на C# для использования на крупном предприятии (ну, т.е., "энтерпрайз"). До недавнего времени пользовался только SVN. Уже давно — лет семь. Всё устраивало. Слышал, разумеется, про git. Знаю, что он "распределенный" в отличие от "централизованного" SVN. Слышал, что возможности git перекрывают возможности SVN, и поэтому он лучше. (Ну ясно же, что если какое-то средство делает все то же, что и другое плюс что-то еще, то оно лучше).

Если вам хватает возможностей SVN, вы вряд ли будете пользоваться дополнительными возможностями GIT. Скорее, они вас будут только раздражать.

Я лично предпочитаю HG. Он очень похож по командам на SVN (и на их общего "идеологического предка", CVS), но при этом распределенный. Плюсом распределенности, лично для меня, является возможность комфортной работы при (временном) отсутствии связи с сервером, и то, что многие операции делаются локально (без сервера), т.е., очень быстро.

Кроме того, мне очень не хватает в SVN нормальных бранчей. Для меня совершенно нормальный workflow, когда нужно сделать фичу, которая требует "рискованных" переделок в существующей codebase, без уверенности, что я нафиг все не наломаю, и что вообще эти переделки пойдут в дело, я создаю бранч, делаю все в нем, и когда все устаканится, вливаю его в trunk.

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

И наконец, это не всем важно, но мне помогает. HG очень легко "натянуть" на уже имеющееся дерево исходников. Т.е., начал что-то ковырять без уверенности, в дело это пойдет или в помойку, потом осознал, что все же в дело, "натянул" на исходники HG. Потом решил, что проект заслуживает копии на сервере — добавить ее тоже не проблема.

_>Несколько раз пытался изучить git и перейти на него, но не понял, что мне это даст. Хотя, в принципе, умом понимаю, что он лучше, что VCS развиваются в этом направлении, и все такое. Недавно предложил мне коллега перейти на git (перевести наш проект). Кстати, над проектом работаем только мы двое. Может, присоединится еще пара человек.
_>Перевели — создали приватный репозиторий на гитхабе. Были трудности с импортом проекта из SVN, история не хотела подтягиваться. Но справились. Ок.

На мой взгляд, GIT очень сложный и слишком непривычный.

_>Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер? Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии. Теперь он мне пишет:

Тут, видимо, дело в настройках. Я уверен, что GIT может работать с простой парольной авторизацией.

HG я вообще использую совместо с ssh, и авторизацией занимается SSH. Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль, но использовать ее не обязательно.

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

SJA>И если мои подозрения верны, и GIT позволяет включать/выключать только на уровне кусков изменений(hunk-ов), то в TortoiseSVN это даже удобнее.

Включать/выключать можно и отдельные строки, если речь об этом.

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

Н>Одно из самых крутых отличий -- в DVCS нужно обязательно (в случае с Mercurial -- именно обязательно, для Git не знаю) коммитить локальные изменения перед тем, как выполнять Merge. Сравнить можно с попытками сделать SVN Update локальной копии с правками, чтобы еще и не потерять оные в случае, если "что-то пошло не так".

Эта обязательность заключается лишь в том, что меркурий, совершенно искусственно, не дает после merge сделать частичный commit (т.е., закоммитить не все измененные файлы).

Это не всегда так было, и не от большого ума сделано. Я даже пытался с ними поспорить на тему необходимости этого ограничения (когда оно появилось). Но они уперлись, а у меня красноречия не хватило

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

_>Да, в гит тоже так, оно и понятно: merge, видимо, производится в репозитории, а потом чекаутится в рабочую копию.

Нет. В репозитории не делается ничего. Репозиторий только хранит информацию. Все остальное делается локально.

SJA>>И если мои подозрения верны, и GIT позволяет включать/выключать только на уровне кусков изменений(hunk-ов), то в TortoiseSVN это даже удобнее.

M>Включать/выключать можно и отдельные строки, если речь об этом.
Да про это. Значит не верно понял, что читал про Git.

Да, действительно на клиенте можно в рамках одной wc легко переключаться между ветками.
Будет только switch to path вместо switch to branch.

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

Pzz> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.

Ай-ай-ай!!! Пароль на ключе должен быть.

Здравствуйте, Хон Гиль Дон, Вы писали:

ХГД>С бинарниками ж вроде гит в последнее время терпимо работает. Т.е., пару лет назад вообще вилы были (мы еще с SVN'овских времен храним в репозитории собранные либы — буст и прочее), иногда коммиты обламывались по нехватке памяти и прочие чудеса творились. А сейчас, тьфу-тьфу, просто тормозит. Но, по-моему, эта скорость вполне на уровне обычной скорости SVN.

Насчёт последнего времени, к сожалению, ничего сказать не могу. Как раз в районе пары лет назад мы столкнулись с тем, что в нашей сборочной системе репозитории стали работать всё тормознее и тормознее, а отдельные перестали клонироваться вовсе. Проблема оказалась в том, что в репы запихали тарболлы с исходниками, и чем больше их накапливалось в истории (и чем больше были сами тарболлы), тем быстрее репозиторий переставал корректно работать. Тогда и нагуглили, что бинарники с гитом не очень дружат, пришлось переделывать систему на хранение тарболлов в отдельном хранилище. Не исключаю, что в последних версиях гита это улучшили, но я не проверял.

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

Pzz>Эта обязательность заключается лишь в том, что меркурий, совершенно искусственно, не дает после merge сделать частичный commit (т.е., закоммитить не все измененные файлы).
Pzz>Это не всегда так было, и не от большого ума сделано. Я даже пытался с ними поспорить на тему необходимости этого ограничения (когда оно появилось). Но они уперлись, а у меня красноречия не хватило

Не понял, какое отношение частичный коммит после мерджа имеет к обязательной "чистоте" рабочей копии.

А насчет того, почему это запрещено -- тут можно поспоритью

В связи с этим возник такой вопрос: можно ли в свн смотреть лог сразу по всем веткам?
Чтобы он показывался не в виде линейной истории, а в виде дерева.

UPD. Конечно же, есть. Например, Tortoise SVN revision graph.
А вот, например, здесь показывается информация о мерджах.

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

M>>Включать/выключать можно и отдельные строки, если речь об этом.
SJA>Да про это. Значит не верно понял, что читал про Git.

В самой консоли это конечно замороченно. Оперировать там можно только с hunk'ами, но фокус в том, что их можно разбивать вплоть до отдельных строк.

В GUI-клиентах обычно все намного проще. В общем, лучше один раз увидеть: картинка

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

Pzz>> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.

AB>Ай-ай-ай!!! Пароль на ключе должен быть.

Зачем?

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

Н>Не понял, какое отношение частичный коммит после мерджа имеет к обязательной "чистоте" рабочей копии.

Допустим, у меня есть N измененных локальных файлов, и я хочу часть изменений выложить в репозиторий, а часть пока не выкладывать.

Если репозиторий успел измениться, и мне надо делать merge, это превращается в аццкий геморрой.

Н>А насчет того, почему это запрещено -- тут можно поспоритью

У них может быть 100500 причин, почему это запрещено, и почему это правильно запрещать, а разрешать не правильно. Оставьте все свои 100500 причин себе, а мне сделайте ручку, которая выключает ваши искуственные запреты.