Здравствуйте, Sinix, Вы писали:
S>* офигенно удобная интеграция с VisualStudio от ankhSvn. Ничего хотя бы отдалённо напоминающего по удобству PendingChanges (см первый скриншот вот тут) для других систем контроля версий нет и походу не предвидится
А можно узнать в чем крутость?? Окно как окно. Вроде во всех гуях окно, в котором коммитят изменения, примерно такой же вид имеет.
Здравствуйте, dmitry_npi, Вы писали:
_>https, а можно по ssh. Я вообще раньше думал, что это одно и то же...
сразу бы вот это написал, и мы бы всё поняли.
*тебе* гит не нужен.
Здравствуйте, Jack128, Вы писали: J>А можно узнать в чем крутость?? Окно как окно. Вроде во всех гуях окно, в котором коммитят изменения, примерно такой же вид имеет.
В юзабилити У AnkhSvn реально получилось сделать пульт управления рабочей копией svn
* Во-первых, окно видно постоянно, оно аттачится как docked panel. Поле с сообщением о коммите можно скрыть, поэтому панель не занимает много места.
* Во-вторых, одним взглядом можно увидеть все сделанные изменения и тикеты, над которыми работаешь (если изменения сгруппированы по changelist). Очень удобно, если нужно восстановить контекст после переключения с задачи на задачу.
* В-третьих, даблкликом по файлу в pending changes можно посмотреть сделанные изменения. Вместе с окном TortoiseMerge — офигенно удобная штука, т.к
tortoise merge умеет схлопывать одинаковый текст.
Для того, чтобы быстро проверить файлы перед коммитом — самое оно.
* В-четвёртых все основные действия: обновить, коммит, откатить и т.д. выполняются в один клик из контекстного меню или вообще с панели инструментов. Удобно, т.к. не надо переключаться со студии на тортойз (или вообще на консоль).
Здравствуйте, CaptainFlint, Вы писали:
CF>Насчёт последнего времени, к сожалению, ничего сказать не могу. Как раз в районе пары лет назад мы столкнулись с тем, что в нашей сборочной системе репозитории стали работать всё тормознее и тормознее, а отдельные перестали клонироваться вовсе. Проблема оказалась в том, что в репы запихали тарболлы с исходниками, и чем больше их накапливалось в истории (и чем больше были сами тарболлы), тем быстрее репозиторий переставал корректно работать. Тогда и нагуглили, что бинарники с гитом не очень дружат, пришлось переделывать систему на хранение тарболлов в отдельном хранилище. Не исключаю, что в последних версиях гита это улучшили, но я не проверял.
А отключать delta compression для этих тарболлов вы не пробовали? Мне помогло в похожей ситуации, правда теоретически должен был заметно увеличится размер репо, но я не проверял, так как этот вопрос меня совсем не волновал.
Здравствуйте, dmitry_npi, Вы писали:
_>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.
Мои личные аргументы очень просты, их 2:
1. Возможность иметь произвольное кол-во локальных бранчей, работая в одной папке.
Это действительно большой плюс. Можно очень быстро переключаться между тасками.
Даже если проект в целом подложен под SVN, делаю в папке локальный гит репозиторий для этой цели.
2. Очень гибкая работа с бранчами. Очень удобно разрабатывать каждую отдельной ветке и автоматизировать интеграцию фичи в релиз бранч(и).
Здравствуйте, BRAhMS, Вы писали:
BRA>Здравствуйте, dmitry_npi, Вы писали:
_>>Итак, что бы я хотел от сообщества? Поймите, я не ретроград, я за изучение новых технологий. Но в данном случае в упор не вижу, чем гит может сделать мою жизнь лучше в сравнении с SVN. Хотелось бы получить действительно убедительные аргументы.
BRA>Мои личные аргументы очень просты, их 2: BRA>1. Возможность иметь произвольное кол-во локальных бранчей, работая в одной папке. BRA>Это действительно большой плюс. Можно очень быстро переключаться между тасками. BRA>Даже если проект в целом подложен под SVN, делаю в папке локальный гит репозиторий для этой цели.
BRA>2. Очень гибкая работа с бранчами. Очень удобно разрабатывать каждую отдельной ветке и автоматизировать интеграцию фичи в релиз бранч(и).
Добавлю еще такую вещь как отсутствие tree conflicts. Не знаю, есть ли эта проблема еще в последних версиях SVN, но меня она бесила конкретно. Поэтому последние пару лет с SVN работаю только через git-svn.
Здравствуйте, Abyx, Вы писали:
A>проще — согласен, только откуда там больше возможностей?
А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial? Если про "легковесные ветки" -- то это Bookmarks и Changeset Evolution. Если про переписывание истории, то тот же Rebase и опять Changeset Evolution.
Наоборот -- это да. В Git'е даже близко нет аналога веток из Mercurial и поэтому, помимо всего прочего, история коммитов изобилует "merged remote tracking branch x/y from zzz".
HgLab: Mercurial Server and Repository Management for Windows
Здравствуйте, Mumitroller, Вы писали:
CF>> <…> Тогда и нагуглили, что бинарники с гитом не очень дружат, пришлось переделывать систему на хранение тарболлов в отдельном хранилище. Не исключаю, что в последних версиях гита это улучшили, но я не проверял.
M>А отключать delta compression для этих тарболлов вы не пробовали? Мне помогло в похожей ситуации, правда теоретически должен был заметно увеличится размер репо, но я не проверял, так как этот вопрос меня совсем не волновал.
К сожалению, не в курсе, этим другие сотрудники занимались.
Здравствуйте, Слава, Вы писали:
С>Для меня в гите есть такая удобная вещь, как stash. Можно засунуть туда локальные изменения для большой и долгой работы, быстренько сделать срочную работу — баги поправить, достать изменения из stash обратно и продолжить.
Здравствуйте, Anton Batenev, Вы писали:
Pzz>> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль.
AB>Ай-ай-ай!!! Пароль на ключе должен быть.
ssh agent же
Откуда же его [независимый суд] взять, если в нем такие же как мы? (c) VladD2
Здравствуйте, Pzz, Вы писали:
Pzz> Pzz>> Авторизация по ключу удобнее, потому что снимает необходимость каждый раз вводить пароль. Pzz> AB>Ай-ай-ай!!! Пароль на ключе должен быть. Pzz> Зачем?
За тем, чтобы в случае его кражи (потеря ноута например), им не смогли просто так воспользоваться (если, конечно, выше не имелся ввиду ssh-agent с небольшим таймаутом хранения).
... в первом классе мне говорили, что нужно делиться, а теперь говорят, что это незаконно ...
Здравствуйте, dmitry_npi, Вы писали:
_>Децентрализация. А зачем она? Проект, перед отправкой заказчику, все равно должен быть собран из центрального репозитория
Незачем было столько писать, достаточно вопроса выше
Децентрализация — это неправильное слово, ближе по смыслу идёт АВТОНОМНОСТЬ, т.к. "децентрализация" подразумевает распределённый по разным физическим серверам сервис (но составляющий единое целое).
DVCS (бросьте это г**но git и юзайте Hg, мой совет) позволяет иметь как бы "карманную VCS", позволяющую делать вообще ВСЁ и при этом БЕЗОПАСНО. Захотел — создал ветку, не понравилось — откатился на год назад. Все эти операции делаются автономно и не затрагивают работу других людей, т.е. вы никому не испортите день, даже если наделали чудовищных изменений в репе. И только после того, как вы наэкспериментировались и добились идеального состояния репа, можно явить миру плод своих страданий — вот в чём радость DVCS! Ну и как бонус, имеем оффлайновый режим работы, позволяющий всё так же контролировать каждую ревизию, но при этом не искать судорожно WiFi, лёжа на "канарах".
Здравствуйте, Нахлобуч, Вы писали:
Н>Здравствуйте, Abyx, Вы писали:
A>>проще — согласен, только откуда там больше возможностей?
Н>А вопросом на вопрос можно? Спасибо. Что такого умеет Git, что не умеет Mercurial? Если про "легковесные ветки" -- то это Bookmarks и Changeset Evolution. Если про переписывание истории, то тот же Rebase и опять Changeset Evolution.
круто, а когда я юзал hg, там еще не было rebase
но я только не понял что делать после ребейза — разве там есть push --force и reset --hard как в гите? чтобы после ребейза залить ветку на сервер и потом синхронизировать другие рабочие копии
и еще, я почитал документацию к rebase и не заметил там --interactive
ну и еще я не понял как массово переписывать историю во всех коммитах, данные автора или коммитера например менять
Н>Наоборот -- это да. В Git'е даже близко нет аналога веток из Mercurial и поэтому, помимо всего прочего, история коммитов изобилует "merged remote tracking branch x/y from zzz".
а вот этого я не понял, и коммитов таких я никогда не видел, только "merge pull request" и обычные "merge branch" иногда
наверное я как-то не так юзаю гит
Здравствуйте, Anton Batenev, Вы писали:
AB> За тем, чтобы в случае его кражи (потеря ноута например), им не смогли просто так воспользоваться (если, конечно, выше не имелся ввиду ssh-agent с небольшим таймаутом хранения).
Во-первых, если украли ноут с ключом (не так уж это и часто происходит, да и кто ж ноуты без ecryptfs держит?), можно просто отозвать (revoke) доступ по нему.
Во-вторых, что в общем-то можно сделать страшного? Запушить коммит удаления всего? Так первый же verify build зарежет. Засунуть в код бекдор? Ревьювер пошлёт. Разрешен прямой push? Ну git revert. Разрешен force push? И что, reflog 30 дней живёт. Сумели зачистить reflog? И что, gc вроде 7 дней loose commits держит. Ну ладно, в худшем случае, если все коллеги по проекту тоже сразу внезапно потеряли свои ноуты с клонами, либо в отпусках и не фетчат изменения, бэкапы забыли настроить, то как минимум останется история до последнего релизного тега, т.е. максимум потеряется изменения текущего спринта.
В общем, единственный нормальный способ удалить данные из git это "rm -rf", притом на всех клонах одновременно.
Здравствуйте, Слава, Вы писали:
С>Для начала: существует TFS, и для ВижуалСтудии он подходит идеально.
У TFS куча своих проблем и особенностей.
С> Всякого рода гиты с эсвээнами для студии все же чужеродны.
Гит, по секрету тебе скажу, сейчас для студии совсем не чужеродный, доступен искаропки и используется внутри МС в том числе и теми, кто пишет студию и инструменты для нее.
С>Не надо. Ключи SSH вообще шифровать необязательно.
Приватный ключ, который на клиенте, все таки надо прятать.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, Sinix, Вы писали:
S> Это только то, что я активно использую.
Ужас. Убожество. Застряли в развитии лет на пять-семь по сравнению с IntelliJ.
Ну ничего, вот clion пилят... Уже можно посмотреть.
Подсветка изменений, прямо в окне редактора. Полоска слева — отмечает для текущего видимого блока, и справа на сколллбаре все изменённые места всего файла. Можно тут же из редактора посмотреть старое значение и откатить, сделать дифф, либо скопировать в буфер обмена. Плюс внизу список изменений, и в дереве проекта изменённые файлики отмечены цветом.
Дифф одного файла. С возможностью тут же поправить. Заметь, подсветка ЯП, навигация по коду, всплывающая инфа никуда не девается как в том же tortoisemerge.
Просмотр лога. В данном случае совместно отображаются коммиты из двух репозиториев (главный проект и third party library). Мержи в логе выглядят как мержи, а не хрен знает что в svn.
Управление ветками, сразу по всем репо.
Ещё суперфича — просмотр истории произвольно выделенного блока текста (с учётом переименований/переносов между файлами). Сложно продемонстрировать скриншотом, к сожалению.
Что все операции работают практически мгновенно (меньше секунды), вроде должно быть очевидно.
Здравствуйте, dmitry_npi, Вы писали:
_>Авторизация. Это вообще жесть. В SVN всё предельно просто: есть логин и пароль, ты их вводишь, сервер их принимает или нет. Для защиты самого пароля есть https. Для того, чтобы скачать с гитхаба, мне пришлось там зарегистрироваться (ну ладно, я уже был зареган), создать какие-то ключи, скачать на рабочий компьютер. На рабочем компьютере с помощью какой-то сторонней программы этот ключ сохранить и ЕЩЕ РАЗ ЗАЩИТИТЬ ЕГО КАКИМ-ТО ДРУГИМ ПАРОЛЕМ. Ну ладно, какое-то время работало и так. Потом что-то стряслось, не помню что, и консольный клиент перестал работать, стал говорить, юзер не найден, доступ запрещен и т.д. Хотя я конфигугрировал это (git --config). _>Почему, скажите, гит не может тупо спросить у меня логин и пароль и отправить их на проверку на сервер? Оказалось, что можно клонировать репу по https, а можно по ssh. Я вообще раньше думал, что это одно и то же... Окей, перебазировал локальную репу на ssh при помощи заклинания, найденного в инете. После этого у меня отвалился еще клиент в студии.
У меня знакомая-гуманитарий разобралась с регистрацией на гитхабе и ключами за пять минут; мне только про https/ssh объяснить и понадобилось.
У AnkhSvn реально получилось сделать пульт управления рабочей копией svn 
Пароль на ключе должен быть.
