Comments 168
TortoiseGit далеко не такой удобный как TortoiseSvn;
У Git не очень хорошо с клиентами под Windows.
С данными пунктами не согласен. На своих проектах использую SourceTree который мне субъективно кажется удобнее чем TortoiseGit/TortoiseSvn. По поводу остальных клиентов под Windows, есть достаточно приличный выбор.
По поводу первого, я не согласен с тем, что клиенты git менее удобны, а не с тем, что TortoiseGit удобнее чем TortoiseSvn. Я имел ввиду что придерживаюсь мнения, что клиенты для git удобнее чем для SVN.
SourceTree появился всего пару лет назад, и то только для макоси. Под винду он вышел попозже. А под линукс до сих пор не вышел.
У Git нет официального консольного клиента для 64-х битной платформы.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
Вы об этом?
Да, эта проблема.
Решение: https://github.com/slonopotamus/wingit/releases
Решение: https://github.com/slonopotamus/wingit/releases
Мне казалось, его давно смерджили в основную ветку.
После перехода с SVN по привычки пытались использовать TortoiseGit, но он оказался не удобен.
В итоге остановились на Git Extensions, он оказался как раз тем что нужно. После этого (уже как пару лет) я стал одним из авторов проекта :-).
В итоге остановились на Git Extensions, он оказался как раз тем что нужно. После этого (уже как пару лет) я стал одним из авторов проекта :-).
Интерфейс
Большое спасибо! Git extensions — очень хороший клиент.
Аналогично. И тоже остановился на GE, хотя перепробовал кучу разных и некоторые были довольно достойны, но мне нравится его простота и отсутствие дизайна.
Примерно таже ситуация, тоже сначала по привычки пыталась использовать TortoiseGit, пока мне не посоветовали Git Extensions. Правда немного тормозит, когда просматриваешь DIff комита с большим количеством файлов.
Под маком SourceTree хорош, а вот под винду пока так себе (видимо ввиду молодости). Так и не смог привыкнуть, вернулся к SmartGit.
Чтобы запустить git-as-svn нужно:Thanks, but no thanks.
Установить Java 8.
Оставлю здесь Visualizing Git Concepts из последнего дайджеста, очень рекомендую покликать если вы начинаете разбираться с Git.
Спасибо! Шикарное наглядное объяснение!
Есть еще красивая обучалка:
pcottle.github.io/learnGitBranching/
pcottle.github.io/learnGitBranching/
Почесав репу и содрогнувшись от связанных с Subversion воспоминаний
Что за воспоминания? Т.е. какая причина при переходе весомее: недовольство svn или преимущества git?
Основную боль в Subversion вызывает то, что нельзя сохранить в системе контроля версий какой-либо промежуточный результат крупных изменений (к примеру: я поменял 100500 файлов, починил компиляцию, но не починил тесты) без разламывания общей версии.
Так же при обновлении нельзя откатиться до состояния «до обновления», т.к. надо разрешить все конфликты любой ценой — обратной дороги нет.
Теоретически это должно решаться ветками, но в Subversion это крайне неудобный механизм.
Так же при обновлении нельзя откатиться до состояния «до обновления», т.к. надо разрешить все конфликты любой ценой — обратной дороги нет.
Теоретически это должно решаться ветками, но в Subversion это крайне неудобный механизм.
А в чём проблема с ветками? Если делаешь что-то большое, создал ветку, переключился на неё, довёл до ума, потом слил в основу, разрешил конфликты, зафиксил — и вуаля.
Так же при обновлении нельзя откатиться до состояния «до обновления», т.к. надо разрешить все конфликты любой ценой — обратной дороги нет.
Просто получите ещё одну рабочкую копию с помощью `svn checkout` и обновите её до любой ревизии которую хотите просмотреть.
Теоретически это должно решаться ветками, но в Subversion это крайне неудобный механизм.
Чем именно-то неудобный?
1) Конфликты, если файл менялся одинаково сразу в двух ветках
2) Слабее чем в git инструментарий для мерджа
3) История в ветке не своя а как бы референс на родительскую ветку. И то только в новом SVN в старом — никакой истории
2) Слабее чем в git инструментарий для мерджа
3) История в ветке не своя а как бы референс на родительскую ветку. И то только в новом SVN в старом — никакой истории
Просто получите ещё одну рабочкую копию с помощью `svn checkout` и обновите её до любой ревизии которую хотите просмотреть.
Допустим:
- я обновился
- поменял 100500 файлов
- попытся закоммитить, но не смог — меня кто-то опередил
- обновился
- мерж 100500 файлов
- запутался и накосячил при мерже
В этой ситуации Subversion не позволяет откатиться к состоянию до начала мержа.
svn checkout даст мне возможность откатиться до начала изменения 100500 файлов, но от этого, обычно, не легче.
Вот как раз поэтому для доработок, затрагивающих 100500 файлов и создают ветки. В отдельной можно спокойно зафиксировать все изменения, а потом уже разбираться с конфликтами с основой, откатываясь сколько угодно. Благо в SVN ветка — это просто пометка в дереве ревизий, не занимающая ни дополнительного места, ни времени.
Благо в SVN ветка — это просто пометка в дереве ревизий, не занимающая ни дополнительного места, ни времени.
Wrong. В SVN ветка — это штуковина, для переключения working copy на которую требуется по меньшей мере O(кол-во файлов) времени. В ситуациях, когда количество файлов в working copy идёт на сотни тысяч или даже миллионы, этот процесс становится неюзабельно медленным.
При переключении между ветками основное время занимает не сравнение, а перекачка изменений. Переключение между ветками с небольшими различиями происходит с вполне вменяемой скоростью. Если же приходится вести параллельно сильно различающиеся ветки, их можно отдельными копиями хранить.
Сколько я ни видел аргументов в пользу Git — все они касаются весьма спорных и практически не встречающихся на практике ситуаций. При правильно организованной работе с SVN Git не даёт сколь-либо весомых преимуществ для того, чтобы переходить на него.
Сколько я ни видел аргументов в пользу Git — все они касаются весьма спорных и практически не встречающихся на практике ситуаций. При правильно организованной работе с SVN Git не даёт сколь-либо весомых преимуществ для того, чтобы переходить на него.
Как долго вы проработали с Git?
Я не работал с Git вообще. Я прочитал несколько статей про него, но не смог найти в них сколь-либо убедительных аргументов в пользу того, чтобы перевести хранилище рабочих проектов с SVN на него.
Предлагаю на этом и закончить.
Вот во всех статьях на этом и заканчивают =).
Мы переходит на Git! А зачем?
Я вполне понимаю людей, которые начинают новый проект на нём. Но за довольно долгое время не встретил ни одного вменяемого аргумента в пользу миграции достаточно большого проекта. И ваш пример в этой статье, к сожалению, исключением не стал.
Мы переходит на Git! А зачем?
Я вполне понимаю людей, которые начинают новый проект на нём. Но за довольно долгое время не встретил ни одного вменяемого аргумента в пользу миграции достаточно большого проекта. И ваш пример в этой статье, к сожалению, исключением не стал.
Для ответа на этот вопрос нужно попробовать поработать с DVCS (Git, Mercurial и т.п.). После этого возникает понимание чем оно лучше/хуже и когда оно уместно.
Для меня толчком для «попробовать Mercurial» стала ситуация когда я писал код без интернета в общественном транспорте.
Первое время оно непривычно и несколько раздражает, потом легче. Git я стал понимать где-то через месяц использования.
Для меня толчком для «попробовать Mercurial» стала ситуация когда я писал код без интернета в общественном транспорте.
Первое время оно непривычно и несколько раздражает, потом легче. Git я стал понимать где-то через месяц использования.
Всё-таки работа над большими изменениями в DVCS и в VCS сильно отличается. В VCS я не могу сохранить текущий стейт локально, иначе как сделав патч. Чтобы продолжить с ним работу после правки какого-нибудь важного бага, например.
Так же в VCS намного сложнее организовать красивый пайплан: отдельные ветки для фичей. Это не невозможно, но это просто сложнее сделать.
Лично мой опыт показывает, что работать с DVCS командой проще, быстрее, эффективнее.
Так же в VCS намного сложнее организовать красивый пайплан: отдельные ветки для фичей. Это не невозможно, но это просто сложнее сделать.
Лично мой опыт показывает, что работать с DVCS командой проще, быстрее, эффективнее.
У Git нет официального консольного клиента для 64-х битной платформы.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
Мне известен только один свежий 64-х битный клиент: github.com/slonopotamus/wingit/releases
Так как Git использует паки через отображение файла на память, использование 32-х битной сборки накладывает серьезное ограничение на размер репозитория.
UFO just landed and posted this here
Стоит уточнить, что в нашем случае речь идет об игровых дизайнерах.
Отвечая на вопрос. По нашему процессу код определяет схему данных (за которые отвечают дизайнеры). Поэтому целостность версии — достаточно ценная штука сама по себе. Ультимативной необходимости это не рождает, но это очень удобно.
Отвечая на вопрос. По нашему процессу код определяет схему данных (за которые отвечают дизайнеры). Поэтому целостность версии — достаточно ценная штука сама по себе. Ультимативной необходимости это не рождает, но это очень удобно.
Дизайнеры не работают с кодом, они работают с данными.
Данные и код сильно взаимосвязаны. Из-за этого желательно держать их в одном репозитории.
Пример из жизни:
Данные и код сильно взаимосвязаны. Из-за этого желательно держать их в одном репозитории.
Пример из жизни:
- программисты пишут блоки для игровой логики;
- дизайнеры составляют используют эти блоки для описания поведения игровых предметов.
Не знаю, работали ли вы в команде с большим количеством не только программистов, но и дизайнеров, и художников. Наша необходимость родилась из опыта. У нас есть крупные проекты на svn, мы пробовали git на более маленьком проекте. Краткие выводы такие: программисты любят git и связанный с ним пайплайн, контент-мейкерам он не подходит (по крайней мере нам не удалось научить их любить git). Это ответ на ваш вопрос.
Зачем мы это опубликовали? Есть мнение, что наша ситуация неуникальна, возможно, кому-то еще пригодится эта разработка. Я не сомневаюсь, что у большинства таких проблем нет, иначе готовых решений было уже достаточно (ибо сама по себе задача не архисложна). Однако кому-то это может помочь.
Зачем мы это опубликовали? Есть мнение, что наша ситуация неуникальна, возможно, кому-то еще пригодится эта разработка. Я не сомневаюсь, что у большинства таких проблем нет, иначе готовых решений было уже достаточно (ибо сама по себе задача не архисложна). Однако кому-то это может помочь.
По опыту контентщики нормально вписываются в гит. Просто нужно через «не хочу».
Это не рокетсайнс, это всего-лишь система контроля версий.
Это не рокетсайнс, это всего-лишь система контроля версий.
Этот разговор можно продолжать бесконечно. У нас есть один опыт (достаточно продолжительный, чтобы считать его валидным), у вас другой. Давайте на этом и закончим.
Если данные нельзя мержить, то Git лишь добавит им проблем без какой-либо выгоды.
Хуже того: же они будут лишены механизма блокировок, который ранее снижал вероятность получения конфликтов.
Хуже того: же они будут лишены механизма блокировок, который ранее снижал вероятность получения конфликтов.
Вы что бинарники в гите храните?
Например в юнити ассеты — бинарники. Мне их на фтп хранить? )
Художники могут хранить svg в гите, хоть и не бинарник, но дифф svg вам не даст вообще ничего.
У нас постоянная проблема с тем, что не программисты не понимают, что такое гит, зачем он им нужен, и почему там все так сложно. С Subversion особых проблем не было, они тыкали себе пару кнопок в клиенте, и жили счастливо. С гитом же начались траблы, уже описанные выше.
Да, конечно, можно их палками научить работать с гитом, но вопрос зачем? Им не нужна полноценная работа с системой контроля версий, зачастую им не нужны ветки и прочие прелести. Им просто нужно находиться в единой инфраструктуре, имея возможность доносить свою работу до остальных участников проекта.
Мы с этой проблемой пока еще не справились.
Да, конечно, можно их палками научить работать с гитом, но вопрос зачем? Им не нужна полноценная работа с системой контроля версий, зачастую им не нужны ветки и прочие прелести. Им просто нужно находиться в единой инфраструктуре, имея возможность доносить свою работу до остальных участников проекта.
Мы с этой проблемой пока еще не справились.
На Mac использую SourceTree, на Windows — GIT Extensions
Субъективно GIT Extensions гораздо мощнее.
Субъективно GIT Extensions гораздо мощнее.
На osx попробуйте tower2. Я попробовал и через месяц купил — ни разу не жалею, отличная штука, гораздо удобнее запутанного source tree, с бОльшим функционалом, чем у GitHub.app.
на самом деле в 90% случаев мне хватает command line, а эти тулы больше для визуального просмотра.
Tower попробую, спасибо.
Tower попробую, спасибо.
Из того, что очень прям понравилось:
— мощный механизм выбора чего коммитить
— возможность раскидать по папкам внутри программы
— раскладывает ветки в стиле gitflow по папкам, такого пока нигде не видел (ну и поддержка gitflow)
— ну и главное — при мерже/ребейзе бекапит состояние и если что — легко откатывает.
Единственное — merge тулза нужна внешняя, если у кого-то есть вменяемый вариант, буду рад услышать.
— мощный механизм выбора чего коммитить
— возможность раскидать по папкам внутри программы
— раскладывает ветки в стиле gitflow по папкам, такого пока нигде не видел (ну и поддержка gitflow)
— ну и главное — при мерже/ребейзе бекапит состояние и если что — легко откатывает.
Единственное — merge тулза нужна внешняя, если у кого-то есть вменяемый вариант, буду рад услышать.
Git Extensions прикольный. Но не все люди видят профит от гит-пайплайна разработки, не всем он нужен. А если преимуществами не пользоваться, то гит вносит оверхед просто своим существованием, тут дело даже не столько в интерфейсе. Цель была в том, чтобы для таких людей оставить простой цикл change-commit.
А для Линукс есть что-нибудь приличное? После TortoiseHg линуксовые git gui теплых чувств не вызывают.
При большом количестве постоянно заливающего народу, люди начинают биться головами (между pull и push успевает кто-то вклиниться).
А вот это как раз привет логика svn. В git для этого офигенный механизм веток, а не всем в
Согласен.
В Git и Subversion разный workflow. И нашей целью было совместить оба варианта.
В Git и Subversion разный workflow. И нашей целью было совместить оба варианта.
А почему нельзя было дизайнерам отвести по ветке, а конечным разработчикам мержить в свои ветки дизайнерские наработки? Это позволит дизайнеру коммитить без напряга, а разработчику удобно подтягивать нужную версию.
Дизайнерские данные непригодны к мержу, увы. Реинтеграция дизайнерских веток превратится в ад для релиз-менеджеров.
Почему в ад? У дизайнера линейная история. Разработчик время от времени мержит себе дизайнерскую ветку.
У одного дизайнера да, но если дизайнеров много, растет вероятность того, что несколько человек потрогает одни и те же бинарники.
Последующий мерж веток этих дизайнеров будет достаточно сложен, если возможен в принципе. Хорошо, если выяснится, что одно изменение из двух было паразитным(сплошь и рядом), куда хуже, если все они — осмысленные.
Разрезолвить такое без потери изменений возможно далеко не всегда.
Последующий мерж веток этих дизайнеров будет достаточно сложен, если возможен в принципе. Хорошо, если выяснится, что одно изменение из двух было паразитным(сплошь и рядом), куда хуже, если все они — осмысленные.
Разрезолвить такое без потери изменений возможно далеко не всегда.
Контент-мейкеры значительно реже пересекаются по данным, для них пайплайн «всем в trunk коммитить» вполне подходит.
UFO just landed and posted this here
Основная проблема: «Git не даёт никаких преимуществ и создаёт дополнительные проблемы, если файлы не поддаются мержу» свойственна всем распределенным системам контроля версий, в том числе и Mercurial-у.
UFO just landed and posted this here
Да, бинарные ассеты.
Это боль, страдание и унижение.
Это боль, страдание и унижение.
UFO just landed and posted this here
Речь не про то, чтобы использовать версионирование. Если бинарные файлы (с которыми в основном работают дизайнеры) не поддаются мержу (не версионированию, а мержу, то есть, например, они бинарные или, например, даже xml-ные, но с таким хаосом в чейнджах, что мержить нереально), то смысла в гите нет, так как нет веток, которые можно потом мержить, и всего прочего, что оставляет дизайнера с линейной историей вполне достаточного svn-а.
Что-то вы по-моему совсем какого-то франкенштейна породили. А нельзя было просто научить дизайнеров использовать гит? Мне кажется это быстрее чем писать такой кастом
Кастом написать один раз, а дизайнеров много. При чем с дизайнерами еще не так страшно, куда сложнее обучить художников.
А какие есть альтернативы?
Мы рассматривали варианты:
Все варианты — дрянь. Приходилось выбирать меньшее зло.
Мы рассматривали варианты:
- Использовать всем Subversion.
Разработчки могут использовать git svn или аналоги, но он не дает возможности работать вдвоём над одной фиче-веткой. Плюс боль и страдание с ветками стабильных версий - Использовать всем Git.
Не вышло. Производительность падает, а недовольство растёт. - Использовать SubGit.
Есть опасение, что мастер-мастер связка репозиториев развалится в самый неподходящий момент. - Переезд на GitHub.
Не подходит, т.к. репозиторий должен быть внутри компании. - Переезд на GitHub Enterprice.
Дорого. - Распилить на два репозитория.
Нужны дополнительные телодвижения для того, чтобы поддерживать соответствие между ними. Особенно тяжело будет при работе со стабильными ветками для боевого кода. - Написать git-as-svn.
Нужно время на разработку и поддержку.
Все варианты — дрянь. Приходилось выбирать меньшее зло.
GitLab.
GitLab, в отличие от GitHub, не позволяет работать с Git-репозиторием через Subversion-клиент.
Зато позволяет работать с репозиторием через веб-морду для тех, кто не умеет в гит.
WEB-морда красивая, но наших проблем она не решает.
В конечном счете, git-as-svn крутится на машине с gitlab-ом и все счастливы.
В конечном счете, git-as-svn крутится на машине с gitlab-ом и все счастливы.
Вместо доработки существующего продукта и/или обучения пользователей вы решили сделать костыль, стимулирующий пользоваться устаревшим ПО. Очень ок.
Я сомневаюсь, что дизайнерам и художникам так уж важно уметь работать с git. Им это скорее совсем не нужно, потому что они пользуються только одной из всех его возможностей.
И использование устаревшего по — не всегда зло. ПО должно максимально эффективно решать задачи, а не быть самым новеньким и клевеньким.
И использование устаревшего по — не всегда зло. ПО должно максимально эффективно решать задачи, а не быть самым новеньким и клевеньким.
Я с этим и не спорю.
И про устаревание я имел ввиду лишь то, что ваша контора, вроде как, решила перейти на Git.
Сам SVN я не считаю устаревшим в общем смысле этого слова.
Подход, когда часть усилий тратится на поддержку костыля — врядли можно называть «максимально эффективным решением задач», проще уж тогда было на SVN остаться.
И про устаревание я имел ввиду лишь то, что ваша контора, вроде как, решила перейти на Git.
Сам SVN я не считаю устаревшим в общем смысле этого слова.
Подход, когда часть усилий тратится на поддержку костыля — врядли можно называть «максимально эффективным решением задач», проще уж тогда было на SVN остаться.
На SVN сложнее делать фичи разработчикам.
На Git — дизайнерам.
А так, ценой некоторых усилий, счастливы все.
На Git — дизайнерам.
А так, ценой некоторых усилий, счастливы все.
Вопрос на самом деле, можете ли вы сделать этот костыль, и что будет выгодней — сделать костыль и поддерживать его, или переучить персонал. Все просто.
Де-факто мы его уже сделали. В данный момент не видно ничего, что может вызвать проблемы с поддержкой или требует крупных усилий для реализации. Все, что нам нужно — уже работает.
Сравнение с переучиванием же несколько не корректно — дело не в том, что они не хотят переучиваться, а в том, что для их работы Subversion объективно лучше подходит.
Сравнение с переучиванием же несколько не корректно — дело не в том, что они не хотят переучиваться, а в том, что для их работы Subversion объективно лучше подходит.
Perforce? мощная система, отлично работает с большими объемами, отличный GUI клиент. Помнится у гита были проблемы с большими репами, размером в 4 гига. Плюс с бинарными данными тоже не все гладко было.
Да, Entreprise solution
Да, за деньги
Да, Entreprise solution
Да, за деньги
Помнится у гита были проблемы с большими репами, размером в 4 гига.
Репозиторий в 4гб — маленький репозиторий. Вот у Apache Software Foundation относительно большой репозиторий — 65гб с 1.5 лямом ревизий.
есть сомнения, что там самый обычный гит сервер. но спорить не буду.
У ASF-то? Я указывал Subversion репозиторий ASF: svn.apache.org/repos/asf/
Для того, чтобы Perforce попал в список рассматриваемых вариантов, кто-то должен был его предложить и объяснить, почему он лучше. Таких людей не оказалось.
Беглый взгляд на Perfoce не выявил никаких преимуществ. К тому же очень настораживает тот факт, что данные о рабочей копии лежат на сервере. То есть для нормальной работы требуется подключение к серверу, причем быстрое.
Беглый взгляд на Perfoce не выявил никаких преимуществ. К тому же очень настораживает тот факт, что данные о рабочей копии лежат на сервере. То есть для нормальной работы требуется подключение к серверу, причем быстрое.
метаданные да, все на сервере живут, это как раз удобно, если много разработчиков, сразу видно, что ктото зачекаутил конкретный файл. вполне хватает впн подключения в другой конец мира. так же есть perforce proxy сервис.
Я допускаю, что Perforce — хороший инструмент.
Но, такова жизнь: пока не появится в команде хоть кто-то, кто с ним работал ранее, вероятность его использования минимальна.
Буду очень признателен, если предоставите хоть какой-то внятный обзор на тему «почему Perforce — хорошо».
Но, такова жизнь: пока не появится в команде хоть кто-то, кто с ним работал ранее, вероятность его использования минимальна.
Буду очень признателен, если предоставите хоть какой-то внятный обзор на тему «почему Perforce — хорошо».
--почему Perforce — хорошо
много лет пользуюсь Perforce, им чаше пользуются гиганты софтиндустрии потому что он платный был практически, а сейчас 20 лицензий бесплатно.
По сравнению с svn — быстрее, интерфейс намного интуитивнее, и может куда больше чем svn.
Примерное дерево с последней работы (50,000 аккаунтов):
— future version 6
— Accepted
— main
— — Accepted 5.0
— — Released 5.0
— — — Service Pack1
— — — Service Pack2
— — — — Walmart — тут патчи для отдельных клиентов
— — — — BOA
— — Accepted 4.6
— — Released 4.6
— — — Service Pack1
— — Accepted 4.5
— — Released 4.5
— — — Service Pack1
Кроме того каждый разработчик создает свои деревья и тока потом может заливать в нужную ветку. В отличии от svn — дерево версий соотвествует дереву на диске всегда.
В отличии от git я никогда не видел чтобы ломался у perforce дипозиторий, может для open-source это некритично, но в любой серьезной организации после такого покажут на дверь.
много лет пользуюсь Perforce, им чаше пользуются гиганты софтиндустрии потому что он платный был практически, а сейчас 20 лицензий бесплатно.
По сравнению с svn — быстрее, интерфейс намного интуитивнее, и может куда больше чем svn.
Примерное дерево с последней работы (50,000 аккаунтов):
— future version 6
— Accepted
— main
— — Accepted 5.0
— — Released 5.0
— — — Service Pack1
— — — Service Pack2
— — — — Walmart — тут патчи для отдельных клиентов
— — — — BOA
— — Accepted 4.6
— — Released 4.6
— — — Service Pack1
— — Accepted 4.5
— — Released 4.5
— — — Service Pack1
Кроме того каждый разработчик создает свои деревья и тока потом может заливать в нужную ветку. В отличии от svn — дерево версий соотвествует дереву на диске всегда.
В отличии от git я никогда не видел чтобы ломался у perforce дипозиторий, может для open-source это некритично, но в любой серьезной организации после такого покажут на дверь.
Я подозреваю, что гиганты софтоиндустрии им пользуются не от того, что он платный, а от того, что он появился до Subversion, Git, Mercurial и пр.
На момент его выхода, если не ошибаюсь, из систем контроля версий были только SourceSafe и CVS.
В любом случае, чтобы составить представление о системе контроля версий с ней нужно поработать хотя бы месяц :)
На момент его выхода, если не ошибаюсь, из систем контроля версий были только SourceSafe и CVS.
В любом случае, чтобы составить представление о системе контроля версий с ней нужно поработать хотя бы месяц :)
С svn я работаю уже пять лет. perforce лишь старше на пять лет чем svn.
Ну, всякие SourceSafe и CVS даже рядом не поставить с Perforce.
На счёт попробовать. Есть public depot. Попробуйте. Perforce — штука здоровская и это начинаешь понимать когда с ним поработаешь какое-то время.
На счёт попробовать. Есть public depot. Попробуйте. Perforce — штука здоровская и это начинаешь понимать когда с ним поработаешь какое-то время.
4 Гб это смешной размер. Он даже много меньше моей рабочей копии.
Лично у меня, git-репозиторий раздувался до ~250Гб (получен через git svn, рабочая копия ~30Гб). Git его вполне нормально переваривал. Mercurial, к слову, развалился на гораздо меньших объемах.
Но нужно отметить, что 32-х битная сборка git-а не может с ним ничего сделать.
Лично у меня, git-репозиторий раздувался до ~250Гб (получен через git svn, рабочая копия ~30Гб). Git его вполне нормально переваривал. Mercurial, к слову, развалился на гораздо меньших объемах.
Но нужно отметить, что 32-х битная сборка git-а не может с ним ничего сделать.
возможно как раз и с 32битной версией сталкивался, давно это было.
Под Windows нет официальной 64-х битной версии Git-а.
Есть не официальная сборка: github.com/slonopotamus/wingit
Есть не официальная сборка: github.com/slonopotamus/wingit
git-репозиторий раздувался до ~250Гб (получен через git svn
Если не нужна вся история, то можно указать с какой ревизии выкачивать.
Perforce ужасен.
- для любого взаимодействия нужно подключение к репе. Даже чтобы узнать, что изменилось в файле
- ме-е-едленный
- мердж — боль
на вкус и цвет…
пришлось с ним работать постольку поскольку.
Наличие постоянного подключения да, требуется, но как-то проблем с этим не возникало. Медленности тоже не замечал. очень непривычно было то, что чтобы отредачтировать файл надо сначала сделать Checkout… Но привык.
пришлось с ним работать постольку поскольку.
Наличие постоянного подключения да, требуется, но как-то проблем с этим не возникало. Медленности тоже не замечал. очень непривычно было то, что чтобы отредачтировать файл надо сначала сделать Checkout… Но привык.
Это Вы ещё StarTeam не щупали.
По первым двум пунктам можно в какой-то степени согласиться, а какие проблемы со слиянием? Есть даже Branch Mappings, упрощающие частое слияние, да и давненько уже появились Streams.
Самый главный минус — невозможность выполнить Resolve вручную, как, к примеру, позволяет тот же Subversion с Postpone Conflict. Из этого следуют следующие проблемы:
— Perforce клиент — гуано (по крайней мере на OS X). И дело даже не юзабилити, а банально в том, что P4Merge постоянно падает, причем в некоторых ситуациях со 100% воспроизведением. Приходится идти в обход. Зачастую просто руками добавлять изменения.
— ме-е-едленно составляется changelist с изменениями, ме-е-едленно, ресолвится каждый файл. Ну и остается проблема с тем, что кто-то уже успел залить новую ревизию, и резолв возобновляется.
Сравните это все с тем же Subversion. Не говоря уже о Git.
> Streams
это хорошо, но в некоторых крупных компаниях до сих пор стоит pre-2011 Perforce без стримов. И обновлять его не собираются. Вопли разработчиков не слышат, утверждая «и так работает».
— Perforce клиент — гуано (по крайней мере на OS X). И дело даже не юзабилити, а банально в том, что P4Merge постоянно падает, причем в некоторых ситуациях со 100% воспроизведением. Приходится идти в обход. Зачастую просто руками добавлять изменения.
— ме-е-едленно составляется changelist с изменениями, ме-е-едленно, ресолвится каждый файл. Ну и остается проблема с тем, что кто-то уже успел залить новую ревизию, и резолв возобновляется.
Сравните это все с тем же Subversion. Не говоря уже о Git.
> Streams
это хорошо, но в некоторых крупных компаниях до сих пор стоит pre-2011 Perforce без стримов. И обновлять его не собираются. Вопли разработчиков не слышат, утверждая «и так работает».
Насколько мне известно, в пользу Perforce постулируются три следующих тезиса:
— Умеет мапить дерево на сервере в другое по структуре дерево в рабочей копии. Этим достигается воспроизводимость environment-а при изменении структуры репы, т.е. связанные проекты можно перемещать в репе относительно друг друга
Лолшто? Хранить билд-конфигурацию в метаданных рабочей копии?
Лолшто №2? Хранить все проекты в одной репе? Да, я знаю, что в Subversion так делали, но это все равно плохо. А в Perforce это поощряется.
— Хорошо справляется с большими бинарниками.
Лолшто? А Subversion плохо справляется? А Git (если его нормально настроить)?
—Ынтерпрайз, пыщ-пыщ Широкие возможности администрирования, в том числе раздача прав доступа
No comments :facepalm:
Итого получается, что Perforce ничем не лучше, но по ряду параметров откровенно всасывает.
— Умеет мапить дерево на сервере в другое по структуре дерево в рабочей копии. Этим достигается воспроизводимость environment-а при изменении структуры репы, т.е. связанные проекты можно перемещать в репе относительно друг друга
Лолшто? Хранить билд-конфигурацию в метаданных рабочей копии?
Лолшто №2? Хранить все проекты в одной репе? Да, я знаю, что в Subversion так делали, но это все равно плохо. А в Perforce это поощряется.
— Хорошо справляется с большими бинарниками.
Лолшто? А Subversion плохо справляется? А Git (если его нормально настроить)?
—
No comments :facepalm:
Итого получается, что Perforce ничем не лучше, но по ряду параметров откровенно всасывает.
Мне просто кажется что время на обучение дизайнеров\художников должно быть меньше чем на разработку и поддержку настолько кастомного решения. Кстати, как долго вы его разрабатывали?
И еще, а что (если это не секрет, конечно) художники складывают в репозиторий?
И еще, а что (если это не секрет, конечно) художники складывают в репозиторий?
Время на разработку ушло не большое — вся история есть на GitHub.
Разработка по остаточному принципу. Задействовано два человека.
- начало разработки: 11 августа 2014 года.
- первая относительно рабочая сборка: 27 августа 2014 года (спустя 16 дней после старта).
Разработка по остаточному принципу. Задействовано два человека.
Исходные данные художников лежат в Subversion.
Там безумные объемы и нет таких жестких требований к соответствию данных и кода.
Там безумные объемы и нет таких жестких требований к соответствию данных и кода.
git svn или аналоги, но он не дает возможности работать вдвоём над одной фиче-веткой.
От чего ж не даёт? Вполне себе даёт. Он создаёт обычные svn-ветки, на которые могут переключиться другие пользователи git/svn.
А вообще, вам не ужа с ежом надо было бы дружить, а воспользоваться меркуриалом.
Не рассматривали подключение svn репозитория как подмодуля? Распиливать, конечно, придётся, но зато синхронизировать можно через pull. Недавно распилил свой на 2 части — фронтендт для верстальщика и бэкенд. Все картинки, к примеру, только в первом, связь через симлинки.
Мысль о разделении на два репозитория рассматривалась, но у нас данные и код слишком сильно связаны и это порождает слишком много проблем. К тому же это потребовало бы частичного дублирования инфраструктуры с коммит-хуками. В результате этот вариант выглядел, как наихудший.
Готовых технических средств для связи Git <-> Subversion я не знаю. То есть в конечном счете это потребовало бы нагромождение других костылей.
В данном же случае получившееся решение выглядит достаточно целостным и устроило обе стороны (и сторонников Git-а, и сторонников Subversion-а).
Готовых технических средств для связи Git <-> Subversion я не знаю. То есть в конечном счете это потребовало бы нагромождение других костылей.
В данном же случае получившееся решение выглядит достаточно целостным и устроило обе стороны (и сторонников Git-а, и сторонников Subversion-а).
Разработчки могут использовать git svn или аналоги, но он не дает возможности работать вдвоём над одной фиче-веткой. Плюс боль и страдание с ветками стабильных версий
Для коллективной работы можно пушить ветку в отдельный git-репозиторий. А результат работы потом мержить в trunk svn-репозитория.
Для коллективной работы можно пушить ветку в отдельный git-репозиторий.
В случае с git svn мы почему-то получали разные git-хэши для одних и тех же svn-коммитов на разных машинах. В причине этого явления не разбирались, но работу через отдельный репозиторий оно делает не возможным.
Причём тут хеши svn-коммитов? Один разработчик заводит git-ветку в git-репозитории, второй её стягивает. Далее работа происходит в чистейшем гите. По окончанию один из разработчиков делает merge или rebase (если нужна история) на мастера (коим является git-svn) и отправляет коммит в svn. Второй разработчик подтягивает коммиты уже из svn. И не важно какие хеши будут у каждого из разработчиков для коммитов из svn, потому что хранилищем у нас является svn, и ссылаться на коммиты нужно по номеру ревизии, а не хешу.
Для слияния веток крайне желательно, чтобы они имели хоть что-то общее. В случае несовпадения хэшей при импорте из svn это будет два независимых дерева.
То есть работать вдвоем, конечно, можно, но для этого нужно, чтобы разработчики клонировали репозитории друг у друга, а не использовали ранее полученные через git svn clone.
То есть работать вдвоем, конечно, можно, но для этого нужно, чтобы разработчики клонировали репозитории друг у друга, а не использовали ранее полученные через git svn clone.
У гитхаба прекрасные клиенты для мака и винды, которые нивелируют проблемы простых смертных. Клиенты вроде можно использовать и без привязки к сервису.
Стремный проект SubGit.
Не могу согласиться с этим утверждением. Используем его уже больше года, проект зарекомендовал себя как надежный и стабильный.
Сама идеология мастер-мастер репликации порождает кучу вопросов:
Мы не знаем, на них ответов и это нас останавливает.
Но, справедливости ради, пока мы тыкали в него палочкой, он вел себя стабильно.
- как делать коммит-хуки?
- какой репозиторий первичен?
- как происходит одновременный коммит через Git и Subversion?
- как делать резервную копию без остановки сервиса?
- как восстановится соответствие репозиториев друг-другу, если в час X отключить питание?
- что делать, если один из репозиториев умрет?
Мы не знаем, на них ответов и это нас останавливает.
Но, справедливости ради, пока мы тыкали в него палочкой, он вел себя стабильно.
То, что SubGit отвечает на некоторые из этих вопросов не так, как Вам нужно, не делает его «стремным». Например, он идеально ложится на наш случай, когда основным репозиторием выступает SVN, в то время как Ваш проект под нее ну совершенно не подходит. Однако это не делает Ваш проект «стремным» в моих глазах.
Мы используем SubGit в проекте без каких-то проблем год, называть его «стрёмным» я бы тоже не стал, свои задачи успешно решает. Заказчик работает с SVN, команда использует git. Не такие счастливые как в Mail.ru чтобы так отвлечься на свой велосипед.
Опишу свой опыт не претендуя на полное знание:
> какой репозиторий первичен?
Это какой-то основной вопрос философии, на ваше усмотрение. У нас это svn, там вся история. В принципе в любой момент можно бросить любой репозиторий, и svn и git и продолжить работу дальше в каком-то одном.
> как делать резервную копию без остановки сервиса?
Резервную копию subgit? Мы не делаем так как потеря с сервера с subgit не приведет к потере данных, а лишь к некоторой потере времени на перенастройку (хотя я вспомнил что VM с subgit на самом деле бэкапится раз в неделю). Если бы требовалось и этот простой устранить, то я не думаю что были бы особые сложности. Не думаю что было бы критично остановить синхронизацию сделать копию и восстановить синхронизацию — все же коммиты в репозиторий это не критичная вещь чтобы несколько минут недоступности ночью коммитов кому-то помешает.
Вообще надо сказать что у subgit есть два режима интеграции с svn (remote и local), мы используем remote.
> что делать, если один из репозиториев умрет?
Subgit создает git репозиторий на основе svn, можно например с какой-то определенной ревизии если вся история в git не нужна для работы. Если умрет git репозиторий, то мы заново пересоздадим его из svn. svn не должен умирать, в нашей среде он админами надежно настроен в плане бэкапов и аппаратного зеркалирования, чтобы не было downtime в случае поломки сервера.
Опишу свой опыт не претендуя на полное знание:
> какой репозиторий первичен?
Это какой-то основной вопрос философии, на ваше усмотрение. У нас это svn, там вся история. В принципе в любой момент можно бросить любой репозиторий, и svn и git и продолжить работу дальше в каком-то одном.
> как делать резервную копию без остановки сервиса?
Резервную копию subgit? Мы не делаем так как потеря с сервера с subgit не приведет к потере данных, а лишь к некоторой потере времени на перенастройку (хотя я вспомнил что VM с subgit на самом деле бэкапится раз в неделю). Если бы требовалось и этот простой устранить, то я не думаю что были бы особые сложности. Не думаю что было бы критично остановить синхронизацию сделать копию и восстановить синхронизацию — все же коммиты в репозиторий это не критичная вещь чтобы несколько минут недоступности ночью коммитов кому-то помешает.
Вообще надо сказать что у subgit есть два режима интеграции с svn (remote и local), мы используем remote.
> что делать, если один из репозиториев умрет?
Subgit создает git репозиторий на основе svn, можно например с какой-то определенной ревизии если вся история в git не нужна для работы. Если умрет git репозиторий, то мы заново пересоздадим его из svn. svn не должен умирать, в нашей среде он админами надежно настроен в плане бэкапов и аппаратного зеркалирования, чтобы не было downtime в случае поломки сервера.
Я допускаю, что у вас SubGit работает и работает хорошо.
Но пока не понятно, по каким принципам он работает, я бы его использовать не рискнул.
Но пока не понятно, по каким принципам он работает, я бы его использовать не рискнул.
Я не знаю точно вашего окружения, так что мне не очень понятно почему вы боитесь рисковать. Что вы теряете если инструмент например, сломается?
Я подумал что мы в своем окружение ничего важного не теряем: svn репозиторий живет отдельной жизнью и хорошо защищен от сбоев и хранит все законченные задачи, git репозиторий внутри subgit потерять не страшно так как его копии обычно есть у всех разработчиков (+ на другом remote, есть у нас некоторые особенности настройки).
С одновременными коммитами в svn и git мы сталкивались, система остается в разруливаемом состоянии (примерно как когда два человека нажимают git push, второй получает ошибку и ему обычно понятно что нужно делать).
Я подумал что мы в своем окружение ничего важного не теряем: svn репозиторий живет отдельной жизнью и хорошо защищен от сбоев и хранит все законченные задачи, git репозиторий внутри subgit потерять не страшно так как его копии обычно есть у всех разработчиков (+ на другом remote, есть у нас некоторые особенности настройки).
С одновременными коммитами в svn и git мы сталкивались, система остается в разруливаемом состоянии (примерно как когда два человека нажимают git push, второй получает ошибку и ему обычно понятно что нужно делать).
Потеря одного репозитория это далеко не худший вариант.
Самое страшное, что может произойти: расхождение содержимого репозиториев.
Пока нет никаких объяснений почему это не может произойти, как это обнаружить и что в этой ситуации делать.
Самое страшное, что может произойти: расхождение содержимого репозиториев.
Пока нет никаких объяснений почему это не может произойти, как это обнаружить и что в этой ситуации делать.
Обнаружить наличие расхождений наверное не очень сложно, просто сравнить рабочие копии.
Опасность ошибок расхождения данных в том, что обычно они всплывают внезапно. При этом между появлением ошибки и её обнаружением проходит значительный временной промежуток.
В контексте того, что репозитории в разных VCS, сравнить их не так просто, как может показаться на первый взгляд. Сейчас я знаю, как это сделать эффективно, но на момент начала истории с написанием git-as-svn у меня этих знаний не было.
Кстати, именно требование отсутствия дублирования данных между Git и Subversion-представлениями явилось причиной нетривиального, с точки зрения реализации, механизма работы с Subversion Properties.
В контексте того, что репозитории в разных VCS, сравнить их не так просто, как может показаться на первый взгляд. Сейчас я знаю, как это сделать эффективно, но на момент начала истории с написанием git-as-svn у меня этих знаний не было.
Кстати, именно требование отсутствия дублирования данных между Git и Subversion-представлениями явилось причиной нетривиального, с точки зрения реализации, механизма работы с Subversion Properties.
А у вас команда разработчиков находится в одном офисе или распределённая? Просто вы указывали в статье, что
Это утверждение относительно верно если команды разрабочиков удалены от Subversion сервера, но Subversion в этом плане можно ЗНАЧИТЕЛЬНО ускорить!
Вы можете настроить репликацию репозиториев и установить репозиторий-зеркало в каждом из офисов чтобы разработчики доступались до ближейшего сервера, а не ходили за океан.
Git, по сравнению с Subversion, нереально быстрый.
Это утверждение относительно верно если команды разрабочиков удалены от Subversion сервера, но Subversion в этом плане можно ЗНАЧИТЕЛЬНО ускорить!
Вы можете настроить репликацию репозиториев и установить репозиторий-зеркало в каждом из офисов чтобы разработчики доступались до ближейшего сервера, а не ходили за океан.
Как разработчик SVNKit, я бы посоветовал вам взглянуть на реализацию SVN сервера на основе нашего DAV сервлета.
Например, разработчики GitHub не скрывали, что посматривают в наши исходники, когда работают над поддержкой SVN на GitHub.
А как разработчик SubGit, я недоумеваю, почему наш продукт стрёмный. SubGit в первую очередь решает задачу постепенной миграции с Subversion на Git, в этом его основное отличие от git as svn; при этом:
— SubGit абсолютно прозрачен для пользователей Git и для пользователей Subversion — поддерживаются все функции обеих систем, то есть наличие SubGit неочевидно для пользователя;
— SubGit'у достаточно обычного удалённого доступа к Subversion репозиторию, чтобы создать Git зеркало этого репозитория;
— Такие компании как Comcast, CBS, Boeing, SpaceX, Cisco, etc. не считают SubGit стрёмным. Наоборот, они его используют в production успешно и не один год.
— Некоторые задачи синхнронизации потребовали нетривиальных решений, и это было одной из самых интересных частей нашего проекта. Это и надёжная репликация, и трансляция информации о merge и поддержка eol-style свойств. Думаю многие из решений заслуживают отдельных постов;
— И да, SubGit — это коммерческий продукт, к которому мы предоставляем не менее коммерческий саппорт, при этом SubGit бесплатен для небольших команд, academic и open source проектов.
Например, разработчики GitHub не скрывали, что посматривают в наши исходники, когда работают над поддержкой SVN на GitHub.
А как разработчик SubGit, я недоумеваю, почему наш продукт стрёмный. SubGit в первую очередь решает задачу постепенной миграции с Subversion на Git, в этом его основное отличие от git as svn; при этом:
— SubGit абсолютно прозрачен для пользователей Git и для пользователей Subversion — поддерживаются все функции обеих систем, то есть наличие SubGit неочевидно для пользователя;
— SubGit'у достаточно обычного удалённого доступа к Subversion репозиторию, чтобы создать Git зеркало этого репозитория;
— Такие компании как Comcast, CBS, Boeing, SpaceX, Cisco, etc. не считают SubGit стрёмным. Наоборот, они его используют в production успешно и не один год.
— Некоторые задачи синхнронизации потребовали нетривиальных решений, и это было одной из самых интересных частей нашего проекта. Это и надёжная репликация, и трансляция информации о merge и поддержка eol-style свойств. Думаю многие из решений заслуживают отдельных постов;
— И да, SubGit — это коммерческий продукт, к которому мы предоставляем не менее коммерческий саппорт, при этом SubGit бесплатен для небольших команд, academic и open source проектов.
SVNKit хороший продукт и его существование значительно сократило нам объем работы.
Но SubGit использует потенциально опасную концепцию мастер-мастер репликации.
Сама идеология мастер-мастер репликации порождает кучу вопросов:
К сожалению, посмотреть на его исходный код, чтобы получить ответы на эти вопросы, мы не можем. При этом есть четкое понимание, что добиться работоспособности этой связки очень и очень не просто.
Ощущение от работы с ним сложилось такое: оно работает, но как — не понятно.
То есть для меня это магическая черная коробка, от которой не понятно, что ожидать в будущем.
Но SubGit использует потенциально опасную концепцию мастер-мастер репликации.
Сама идеология мастер-мастер репликации порождает кучу вопросов:
- как делать коммит-хуки?
- какой репозиторий первичен?
- как происходит одновременный коммит через Git и Subversion?
- как делать резервную копию без остановки сервиса?
- как восстановится соответствие репозиториев друг-другу, если в час X отключить питание?
- что делать, если один из репозиториев умрет?
К сожалению, посмотреть на его исходный код, чтобы получить ответы на эти вопросы, мы не можем. При этом есть четкое понимание, что добиться работоспособности этой связки очень и очень не просто.
Ощущение от работы с ним сложилось такое: оно работает, но как — не понятно.
То есть для меня это магическая черная коробка, от которой не понятно, что ожидать в будущем.
Раз представилась такая возможность, хочу поблагодарить Вас за SubGit. Пользоваться им — сплошное удовольствие! Прямо как мостик в нормальный мир из SVN ада :)
Я использую Git Extensions и субъективно он на порядок удобнее любых других клиентов которыми я ранее пользовался. Единственные слабые места которые всплыли за годы работы — это работа с субмодулями и неудобный поиск коммитов по хэшу. Tortoise Git по сравнению — тихий ужас, имхо. Консоль — вообще непонятно зачем нужна при наличии позволяющего сделать все без нужды копать мануал Extensions.
У нас конечно не очень большой коллектив (человек 20 работает с репозиторием), но работа там идет довольно активная и этого вполне достаточно чтобы часто столкнуться с тем что «делаешь Push а тебя уже опередили». Абсолютно никаких проблем в git это не создает. Работаешь себе спокойно в локальном репозитории сколько нужно, затем делаешь pull с одновременным merge или rebase. В 90% он происходит автоматически, в оставшихся 10% ручками правишь то что не смержилось. Дальше делаю push. Не прошло? Делаю снова pull + rebase / merge. Поскольку времени между соседними pull-ами прошло немного, то почти наверняка во второй раз все проходит автоматически, исключения встречаются буквально раз-два в год. Сразу после этого делаю push. Третьей итерации pull-push на моей памяти практически никогда не бывает. Очень легко, прозрачно и удобно все делается.
Впрочем в Гите довольно глупо работать всем в одной ветке. Я все чаще создаю по новой ветке на каждую задачу над которой работаю и подмердживаю в неё правки из главной ветки по мере необходимости. При этом я никому заведомо не мешаю своим кодом, мне тоже никто не мешает, я держу весь код в репозитории на серваке, но при этом сам решаю когда мне мержиться и у меня НИКОГДА не возникает нужды делать повторный мердж потому что кто-то еще что закоммитил и я не могу запушить свои изменения. Каждый мерж конфликт в подавляющем большинстве случаев фиксится лишь один раз и дальше Git в подавляющем большинстве случаев к этому конфликту никогда не возвращается. Когда я достигаю в задаче определенного майлстоуна я мержу мастер в свою ветку в последний раз, правлю при необходимости конфликты, проверяю что все работает и мерджу свою ветку обратно в главную. При этом все мержи из моей ветки автоматически сливаются в единый большой осмысленный коммит и мерж проходит легко и безболезненно. При условии что каждый девелопер работает похожим образом число коммитов в главную ветку получается очень невелико и вероятность того что они произойдут одновременно очень мала; плюс в главной ветке в любой момент времени живет только протестированный и полностью сделанный код, а не некий «полуфабрикат» в котором часть ревизий указывает на плохие или недоделанные билды. Эта схема начинает давать сбои только в ситуации когда один код очень сильно в разные стороны правится двумя людьми и быстро расходится к двум совершенно разным версиям кода в разных ветках, но в такой ситуации по-любому будет тонна мерж конфликтов
У нас конечно не очень большой коллектив (человек 20 работает с репозиторием), но работа там идет довольно активная и этого вполне достаточно чтобы часто столкнуться с тем что «делаешь Push а тебя уже опередили». Абсолютно никаких проблем в git это не создает. Работаешь себе спокойно в локальном репозитории сколько нужно, затем делаешь pull с одновременным merge или rebase. В 90% он происходит автоматически, в оставшихся 10% ручками правишь то что не смержилось. Дальше делаю push. Не прошло? Делаю снова pull + rebase / merge. Поскольку времени между соседними pull-ами прошло немного, то почти наверняка во второй раз все проходит автоматически, исключения встречаются буквально раз-два в год. Сразу после этого делаю push. Третьей итерации pull-push на моей памяти практически никогда не бывает. Очень легко, прозрачно и удобно все делается.
Впрочем в Гите довольно глупо работать всем в одной ветке. Я все чаще создаю по новой ветке на каждую задачу над которой работаю и подмердживаю в неё правки из главной ветки по мере необходимости. При этом я никому заведомо не мешаю своим кодом, мне тоже никто не мешает, я держу весь код в репозитории на серваке, но при этом сам решаю когда мне мержиться и у меня НИКОГДА не возникает нужды делать повторный мердж потому что кто-то еще что закоммитил и я не могу запушить свои изменения. Каждый мерж конфликт в подавляющем большинстве случаев фиксится лишь один раз и дальше Git в подавляющем большинстве случаев к этому конфликту никогда не возвращается. Когда я достигаю в задаче определенного майлстоуна я мержу мастер в свою ветку в последний раз, правлю при необходимости конфликты, проверяю что все работает и мерджу свою ветку обратно в главную. При этом все мержи из моей ветки автоматически сливаются в единый большой осмысленный коммит и мерж проходит легко и безболезненно. При условии что каждый девелопер работает похожим образом число коммитов в главную ветку получается очень невелико и вероятность того что они произойдут одновременно очень мала; плюс в главной ветке в любой момент времени живет только протестированный и полностью сделанный код, а не некий «полуфабрикат» в котором часть ревизий указывает на плохие или недоделанные билды. Эта схема начинает давать сбои только в ситуации когда один код очень сильно в разные стороны правится двумя людьми и быстро расходится к двум совершенно разным версиям кода в разных ветках, но в такой ситуации по-любому будет тонна мерж конфликтов
Именно по этому программисты и любят Git.
Выбор клиента тут имеет второстепенное значение.
Проблема в другом: у дизайнеров файлы бинарные и слияние не возможно в принципе. Из-за этого все телодвижения с локальными ветками теряют смысл и превращаются в обузу. Локальные коммиты при этом становятся вредными, так как только увеличивают вероятность конфликта.
Выбор клиента тут имеет второстепенное значение.
Проблема в другом: у дизайнеров файлы бинарные и слияние не возможно в принципе. Из-за этого все телодвижения с локальными ветками теряют смысл и превращаются в обузу. Локальные коммиты при этом становятся вредными, так как только увеличивают вероятность конфликта.
Мы для авторов статей сделали свой интерфейс, который в фоне на самом деле коммитит правки в git. По принципу — кто последний, тот и прав.
И никаких проблем.
P.S.: и да, для контента отдельный git-репозиторий.
И никаких проблем.
P.S.: и да, для контента отдельный git-репозиторий.
Принцип «кто последний, тот и прав», как минимум, сомнителен. В нашем случае с одними и теми же данными могут работать разные люди. Потеря изменений «втихую» недопустима, так как обнаружится через очень продолжительное время.
Реализация своего интерфейса не рассматривалась по той причине, что у многих программ есть готовая интеграция с Perforce и Subversion, но нет интеграции с Git. Подменяя интерфейс на стороне сервера мы автоматически используем встроенную интеграцию без необходимости допиливать каждый инструмент для использования с Git-ом.
Реализация своего интерфейса не рассматривалась по той причине, что у многих программ есть готовая интеграция с Perforce и Subversion, но нет интеграции с Git. Подменяя интерфейс на стороне сервера мы автоматически используем встроенную интеграцию без необходимости допиливать каждый инструмент для использования с Git-ом.
Простите, а вы ПРАВДА не смогли своих гениальных разработчиков перевести с тормозного SVN на скоростной GIT?
— если не fast forward — загружаем последние изменения из git-коммитов и идём к шагу 2;Вот этот шаг был сделан очень зря. Потому что Subversion в таких случаях выдавал ошибку — и не просто так…
Subversion не выдавал в таких случаях ошибку. Для коммита через Subversion достаточно, чтобы изменения коммита не пересекалось с другими изменениями. При этом не обязательно, чтобы рабочая копия была обновлена до последней версии.
В нашем случае это поведение сохраняется.
В нашем случае это поведение сохраняется.
Хм, не замечал. Наверное, у меня просто никогда не встречалось непересекающихся коммитов…
В Subversion это настолько естественно, что этого не замечаешь.
Самый простой способ:
Но по большому счету, повторная попытка заливки нужна из-за того, что кто-то может параллельно совершить git push в ту же ветку.
Если бы мы просто вернули ошибку в случае «не fast forward», то при повторной попытке коммит мог бы пройти у пользователя, что выглядит странно. При текущем же поведении, если первая попытка закоммитить не прошла, то второй раз пытаться не имеет смысла — будет та же ошибка.
Самый простой способ:
- обновиться
- поменять два файла
- закоммитить первый файл
- закоммитить второй файл — в этом месте рабочая копия уже не от последней ревизии
Но по большому счету, повторная попытка заливки нужна из-за того, что кто-то может параллельно совершить git push в ту же ветку.
Если бы мы просто вернули ошибку в случае «не fast forward», то при повторной попытке коммит мог бы пройти у пользователя, что выглядит странно. При текущем же поведении, если первая попытка закоммитить не прошла, то второй раз пытаться не имеет смысла — будет та же ошибка.
После коммита первого файла текущая ревизия обновится — и к моменту коммита второго файла рабочая копия все равно будет от последней ревизии.
Извиняюсь, что так долго отвечал — под рукой не было SVN, чтобы проверить.
Извиняюсь, что так долго отвечал — под рукой не было SVN, чтобы проверить.
После коммита первого файла текущая ревизия обновится — и к моменту коммита второго файла рабочая копия все равно будет от последней ревизии.
Это не так. Ревизия обновляется только у элементов, которые непосредственно участвуют в коммите. Данные о втором файле будут от предпоследней ревизии.
Сама рабочая копия будет от смешанной ревизии (см. вывод svnversion).
Мы, кстати, эту особенность используем при изменении svn properties: если закоммитить изменения .gitattibutes/.gitignore, то при следующем обновлении поменяются свойства всех файлов, которые «затронуты» его изменением.
Сделайте тогда лучше систему блокировки файлов и не морочьте людям голову. Когда-то в CVS была какая-то.
В данной ситуации проще всего было использовать Mercurial.
Там нормальный клиент под винду, более понятная для перехода от SVN система команд, а чтобы выстрелить себе в ногу надо-таки выстрелить себе в ногу, а не сделать что-то с виду безобидное. SVN-like процесс для дизайнеров можно добавить, дописав небольшое расширение.
Там нормальный клиент под винду, более понятная для перехода от SVN система команд, а чтобы выстрелить себе в ногу надо-таки выстрелить себе в ногу, а не сделать что-то с виду безобидное. SVN-like процесс для дизайнеров можно добавить, дописав небольшое расширение.
Как я уже писал выше:
Основная проблема: «Git не даёт никаких преимуществ и создаёт дополнительные проблемы, если файлы не поддаются мержу» свойственна всем распределенным системам контроля версий, в том числе и Mercurial-у.
Это не совсем так.
Насколько я понял, вам нужен SVN-like update и SVN-like commit.
Их на мерке организовать довольно-таки просто и без риска отстрела конечностей.
В части скорости выполнения команд, логов, чекаутов и т.п. любая DVCS даст SVN сто очков вперед.
В вашем же случае и разработка сложнее и абстракции дырявее, и родовые недостатки SVN у дизайнеров останутся.
Насколько я понял, вам нужен SVN-like update и SVN-like commit.
Их на мерке организовать довольно-таки просто и без риска отстрела конечностей.
В части скорости выполнения команд, логов, чекаутов и т.п. любая DVCS даст SVN сто очков вперед.
В вашем же случае и разработка сложнее и абстракции дырявее, и родовые недостатки SVN у дизайнеров останутся.
SVN-like update и SVN-like commit это только макушка айсберга.
Суть проблемы в том, что можно выделить два варианта работы с системой контроля версий:
Внезапно выяснилось, что:
Реализация Subversion-протокола на серверной стороне позволило совместить оба подхода и при этом:
Суть проблемы в том, что можно выделить два варианта работы с системой контроля версий:
- Основанный на слияниях: взял версию -> начал править -> слил изменения -> залил
Этот подход используется, как в DVCS, так и в Subversion. - Основанный на блокировках: взял блокировку -> начал править -> залил и снял блокировку
Этот подход может использоваться в Subversion и Perforce.
Внезапно выяснилось, что:
- выбор подхода сильно зависит от инструментария и данных (у картинок, к примеру, нельзя совместить изменения);
- оба подхода могут быть на одном проекте (дизайнеры vs программисты);
- многий инструментарий, ориентированный на работу через блокировки, не имеет интеграции ни с одной DVCS системой;
- дизайнеры очень не хотят терять результат дневной работы из-за отсутствия блокировок.
Реализация Subversion-протокола на серверной стороне позволило совместить оба подхода и при этом:
- держать данные проекта в одном репозитории;
- избавиться от проблем, возникающих при разбивке на два разнотипных репозитория;
- избавиться от необходимости впиливания интеграции с DVCS в используемом инструментарии.
Вы же в курсе, что в svn «блокировки» на самом деле ничего не блокируют, а только лишь ставят аттрибут read-only на файлах в рабочей копии? При этом узнаёшь о том, что стоит этот аттрибут, лишь когда пытаешься сохранить изменённый файл и тебе предлагают выбор между «выкинуть свою работу в корзину» и «сохранить всё-равно».
Боюсь, что вы что-то путаете: блокировки в Subversion живут на стороне сервера и учитываются при попытке закоммитить заблокированный файл. То есть это не просто «флажок read-only».
Проблема со взятием блокировки в начале изменения данных до сохранения, к сожалению, решается только интеграцией инструментария с системой контроля версий.
Проблема со взятием блокировки в начале изменения данных до сохранения, к сожалению, решается только интеграцией инструментария с системой контроля версий.
Да, видимо спутал с атрибутом svn:needs-lock
Кстати да, про svn:needs-lock забыл :)
Может позже добавим: github.com/bozaro/git-as-svn/issues/64
Может позже добавим: github.com/bozaro/git-as-svn/issues/64
Ну, надо просто чаще сохраняться (и чаще делать svn up). Все-таки между «не смог сохраниться и потерял полчаса работы» и «не смог смерджить изменения и потерял 2 дня работы» огромная разница.
Это все понятно, непонятно другое — почему для реализации блокировок обязательно надо эмулировать SVN?
Я полагаю, что это связано не с DVCS вообще, а с гитом в частности.
Я полагаю, что это связано не с DVCS вообще, а с гитом в частности.
UFO just landed and posted this here
Mercurial в данной ситуации ничем не лучше. При работе над немержабельными бинарниками все DVCS одинаково плохи. А так — мы и на Git'е организовали SVN-like процесс, дописав небольшое расширение (git-as-svn).
Не скажите. Гит очень уж по-челябински суров. Блокировки же к существующей DVCS можно приделать и без эмуляции SVN.
Блокировки не могут быть реализованы отдельно за дешево. Сферические блокировки в вакууме никому не нужны.
Помимо реализации блокировок в VCS нужно еще добавить интеграцию с ними во всем используемом инструментарии (причем, включая тот, которым мы потом захотим пользоваться), а это очень большой объем работы.
Помимо реализации блокировок в VCS нужно еще добавить интеграцию с ними во всем используемом инструментарии (причем, включая тот, которым мы потом захотим пользоваться), а это очень большой объем работы.
Sign up to leave a comment.
Git as Subversion