Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alvas, Вы писали:
A>>У Mercurial вроде как есть интергация с Visual Studio.
IT>У GitExtensions тоже есть. Вполне достаточная для работы с ним.
В статье утверждалось
Из существующих GUI для обеих систем можно выделить, пожалуй, Git Extensions для Git и TortoiseHg соответственно для Mercurial. Первый инструмент представляет собой отдельное приложение с очень лёгкой интеграцией с Visual Studio, второй сделан по образу и подобию TortoiseSVN в виде расширения оболочки Windows. Не вдаваясь в подробности, скажу лишь, что то, что русскому хорошо, немцу – смерть. На мой взгляд, работа с репозиторием как со структурой файлов вполне оправдана в случае с Subversion, но совершенно не подходит для репозиториев Git или Mercurial, по той причине, что в Subversion мы работаем с деревом каталогов, а в Git или Mercurial – с деревом коммитов. К тому же разработчики TortoiseHg находятся в состоянии затяжного творческого поиска и когда они из него выйдут совершенно не ясно.
Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
В Git нет команды переименования/перемещения файлов. Тем не менее, Git пытается выполнять эту работу автоматически. Чтобы гарантированно сохранить историю переименований, сделайте коммит, потом выполните переименования/перемещения файлов и сделайте ещё один коммит. Точное совпадение содержимого файлов даст гарантию сохранения истории. Если же вы одновременно переименуете и измените файл, то такой гарантии не будет.
Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
Можно подумать ты учился читать не по букварю с картинками, а сразу по Войне и Миру.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Roman Odaisky, Вы писали:
RO>>Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
IT>Можно подумать ты учился читать не по букварю с картинками, а сразу по Войне и Миру.
Я наоборот формат статьи считаю действительно здоровским. В отличие от Hg в картинках от Джоела Спольски, например. Почистить только небольшие огрехи (в этой ветке предложенные, например) + убрать рекламный глянец (на аудиторию он не действует — скорее наоборот)
ИТ>Авторы: ИТ> Игорь Ткачев
ИТ>Аннотация: ИТ>Краткое введение в Git и Git Extensions.
Я уже более десятка лет использую самые разные системы контроля версий, но за всё это время мною было создано веток меньше, чем при написании этой статьи.
RO>Git — это хорошо, но я было подумал, что картинки будут вроде этих: http://nvie.com/posts/a-successful-git-branching-model/. Скриншоты? Мне кажется намного более актуальным разъяснение того, чего можно добиться с помощью Git или аналогов, и какие подходы при этом рекомендуются, а не картинки, где какие открыть окна и какие жать кнопочки.
Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, alvas, Вы писали:
A>>У Mercurial вроде как есть интергация с Visual Studio.
IT>У GitExtensions тоже есть. Вполне достаточная для работы с ним.
А картинки к интеграции есть? Что -то в статье не заметил.
Здравствуйте, Аноним, Вы писали:
А>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.
Мессия — только человек, причём в контексте религии. Долго пытался понять смысл предложения, прежде чем осознал неуместное использования слова.
Любой коммит (от англ. commit) в Git производится в локальный репозиторий, а затем эти изменения при необходимости проталкиваются на сервер. Т.е. чтобы сделать коммит на сервер, нужно нажать не одну кнопку, а две. В некоторых случаях это даже удобно. Например, можно лететь в самолёте, при этом писать код и периодически сохранять свои изменения в локальный репозиторий, не соединяясь с центральным сервером. Прикольно, конечно, но в целом удобство такой возможности весьма сомнительно. Как часто вы летаете в самолётах, а как часто при этом пишете код? Стоит ли менять систему контроля версий только из-за такой возможности? Скорее всего, вряд ли.
Вообще нет, это очень важно. DVCS подкупили меня не распределённостью, которой я пользуюсь крайне редко, а именно локальными комитами, видимыми только мне контрольными точками к которым можно откатиться. Возможность безболезненно эксперементировать, рефакторить не боясь ошибиться бесценна. Лично для меня именно локальные комиты были решающим аргументом.
Из существующих GUI для обеих систем можно выделить, пожалуй, Git Extensions для Git и TortoiseHg соответственно для Mercurial.
Для меркуриала есть аж две интеграции с Visual Studio. Я пользуюсь VisualHG. Её не заметно, просто работает.
Не увидел аналога Preview incoming changes from remote repository. Это как pull, но локальный репозиторий не изменяется.
Не раскрыт вопрос аутентификации и авторизации.
Не раскрыт вопрос работы с большими файлами. Mercurial, например, выделяет оперативную память под файл непрырывным куском,поэтому с файлами больше 200-300Мб работать сложновато.
Не раскрыт вопрос работы с двоичными файлами. Mercurial, например, считает двоичным любой файл в котором есть нулевой байт, в том числе текстовые файлы в кодировке UTF-16.
Здравствуйте, CaptainFlint, Вы писали:
CF>Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
Это что правда так? Нельзя одновременно менять и переименовывать файлы с сохранением истории? Какое убожество, как я люблю меркуриал.
Здравствуйте, adontz, Вы писали:
CF>>Не совсем так. Во-первых, команда-таки есть: git mv. Во-вторых, если одновременно попытаться переименовать и изменить файл, то в этом случае не просто "не будет гарантии", а, наоборот, будет гарантия, что связь между старым и новым файлом уничтожится (старый файл удалён, новый добавлен). Сохранить в коммите запись о том, что файл был одновременно и переименован, и изменён, невозможно.
A>Это что правда так? Нельзя одновременно менять и переименовывать файлы с сохранением истории?
Когда мне это потребовалось, я довольно долго рылся в поисках решения, и всё, что нашёл, — это утверждения о невозможности такого действия одинарным коммитом. Не исключаю, что в последних версиях что-то такое добавили. Вообще, насколько я слышал, Git и Hg по функциональности практически идентичны и различаются лишь подходом к выполняемым операциям, а если в одном из них появляется что-то новое, другой то же самое быстренько реализует и у себя.
Если нам не помогут, то мы тоже никого не пощадим.
