modern DVCS

[wizzard]

я вот тут решил попробовать мигрировать на новомодные нынче git/hg, и возник вопрос – а в них как вообще чекаутить часть репозитория?

а то у меня то ли снега нету, то ли лыжи не едут, в общем, не вижу я этого в упор в документации, и всё…

зачем это нужно:
а) разделение прав доступа девелоперов к частям проекта, вплоть до отдельных файлов (сертификаты, например)
б) если репо более 10-20 Гб, чекаутить его весь неудобно, как бы быстро это ни происходило. да, я держу в версионнике медиа-контент, а не только текст. версионировать его отдельно – это можно чокнуться.

Comments

[dkrnl.livejournal.com]

а в них как вообще чекаутить часть репозитория?
тоже мучился с этим, так и остался на svn, вроде говорят "ты не должен этого хотеть".

[wizzard]

ну да.. а в свине я уже 30 минут пытаюсь сделать merge reintegrate, который рушится, если VPN моргнет, и оставляет битый локальный вариант репоза - тоже плохо, блин. отчего и дергаюсь по сторонам.

[metaclass.livejournal.com]

В меркуриале этого нет.

[wizzard]

Плохо! :)

[blacklion.livejournal.com]

Делай отдельные репо, увы.

[maxim.livejournal.com]

+1

[gds.livejournal.com]

вдобавок к сказанному, в меркуриале есть расширения, позволяющие работать с пачками репозиториев: http://mercurial.selenic.com/wiki/Subrepositories?action=show&redirect=subrepos
Сам не пользовал, мопед не мой.

[dkrnl.livejournal.com]

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

[lionet.livejournal.com]

А почему версионировать медиа-контент — чокнуться? Зачекаутил один раз и версионируй сколько влезет. В git это быстро.

[wizzard]

"версионировать его отдельно – это можно чокнуться"
ключевое слово "отдельно" - менеджить несколько репозиториев одновременно, имхо, неудобно. В каких багтрекерах это считается штатным режимом работы?

А если чекаутить весь репо сразу - несколько веток могут и на винт не влезть, например :)

[lionet.livejournal.com]

Ветки в том же git переключаются, а не хранятся в копиях. Переключение зело быстро.

[wizzard]

Переключаются да. Только binary diff на чуть разных вариантах отрендеренных анимаций (по крайней мере, в 2008-2009 году в версионнике у меня на работе лежали именно они) работает плохо, и репоз все равно большой.

А выбрасывать и считать их продуктом билда низзя, ибо билд, длящийся 3-4 суток, никого не устраивает.

[lionet.livejournal.com]

Свитч бранча в git не делает diff тех файлов, про которые известно, что они не изменились между свитчующимися бранчами.

То есть, git checkout branchA / git checkout branchB при отсутствии разницы между бранчами будет выполняться за 10 миллисекунд.

[wizzard]

Сорри, но мы говорим про чуть разные вещи - я говорю про "размер итогового репозитория", а ты - про "время проведения операции над репозиторием".

К скорости работы гита у меня претензий нет ;)

Вообще, спасибо за разговор)

[wizzard]

Да, а проблема с правами доступа в том, что в патологическом случае права доступа - это матрица user * resource, а если делить на репозитории-"компоненты", то может в итоге так случиться, что будет по репозу на папку\файл (что неудобно), или каждому юзеру будет по отдельному мелкому репозу, и тогда немного непонятно, зачем вообще версионироваться (ну, кроме бекапов)

[lionet.livejournal.com]

С правами доступа в _D_VCS традиционно не заморачиваются. Ибо архитектурно неприятно.

[wizzard]

Да, я понимаю, что central authority нету, а без нее надо много заморачиваться с графом доверия. Также, насколько я понимаю, гит быстрее, т.к. ему не надо для операций ходить к этой самой авторити.

В связи с этим вопрос - не бывает ли версионников, которые выполняют операции типа того же свича\мержа на сервере, а секьюрити управляют на границе "сервер-девелопер"?

[lionet.livejournal.com]

Примерно то, что тебе нужно — svn, perforce, clearcase ;)

[wizzard]

Эх ;)

[kurilka.livejournal.com]

есть gitosis, но у нас очень несложное разделение прав (релизят ответственные)

[109.livejournal.com]

а чем плох ms team server?

[wizzard]

дома нету машины чтоб поставить и поиграться; на работе билд-сервер на BSD.

а так вообще я на него поглядываю, да.

[ens-a-se.livejournal.com]

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

[109.livejournal.com]

а конкретнее? в чём капец?

[ens-a-se.livejournal.com]

Если сделать что-то не так то он говорит ужасные ошибки. Например, как то раз я переместил папку в ветке unstable и жил и радовался. Потом надо было забранчить в ветку stable - сразу куча ругани, надо думать, разбираться и тп. С hg проще.
Потом TFS - ужасен в плане поменять файлы снаружи. Мне часто нужно зайти в фаре и поменять vcproj руками а не через проперти. Потому что так быстрее. Надо сделать чекаут бла-бла.
Нельзя переместить несколько файлов сразу. Те я ожидаю что гуйня для TFS дает как минимум то же удобство что и хотя бы проводник. Но нифига.
С тасками там вообще гуи на уровне конца 90х. бе.

[ens-a-se.livejournal.com]

понятно, что со временем привыкаешь к нему. Но опенсорсные штуки и удобнее и проще. честно. порог вхождения на порядок ниже

[109.livejournal.com]

ха, претензии к гуйне? когда у других вообще гуя нет?

и можно же настроить, чтобы менять, не делая чекаут. для этого надо просто чекинить, оставляя файлы checked out. не знаю только, зачем это может быть нужно (пример с фаром не катит - возьми и сделай чекаут руками. всяко лучше, чем все файлы держать всё время чекаутными.)

а что такое hg?

[ens-a-se.livejournal.com]

там есть гуйня - Tortoise SVN/Mercurial. Там фича в том что используются существующие тулы для просмотра файлов - проводник. А если под фаром то можно прямо в консоль.
настроить - да можно. но там как-то все так не интуитивно понятно. сложно объяснить - но с TFS я каждый раз хлебаю горя. В случае с SVN там как-то было просто все чинить руками. Зашел в файлик какой-нить, поправил ченить - опять заработало.
а ну hg - это я имел ввиду Меркуриал.

[109.livejournal.com]

спасибо, попробую. а то TFS слишком много ресурсов жрёт.

Hg

[bik-top.livejournal.com]

>в них как вообще чекаутить часть репозитория?

В Hg для «чекаутить» ближе всего операция «клонировать». Так вот, клонировать можно только весь репозиторий целиком; при этом можешь создать 0 или 1 рабочую директорию — тоже целиком.

У нас для пунктов а) и б) отдельные репозитории. Обычный паттерн — для проекта MyProject помимо основного центрального репозитория создаётся ещё: а) репозиторий MyProject.Sandbox — это всякие прототипы и эксперименты, заказчику он не отдаётся, права на чтение/запись только у некоторых разработчиков; б) репозиторий MyProject.Externals, для сторонних библиотек и бинарного контента (желательно не «производного» от исходников). Последний подрубается как subrepo; если он становится слишком тяжёлым, не жалко просто сбросить его историю, не затрагивая историю основного репозитория.

>если репо более 10-20 Гб...

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

[zeux.livejournal.com]

Есть еще одна проблема с медиа контентом - т.к. он типично не мержится принципиально, то при работе нужен централизованный сервер, раздающий локи (который не может быть git/hg), либо настолько грамотно спланированная работа, чтобы concurrent edits не возникали в принципе (думаю, так не бывает).