Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 299
> Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку ".svn"
ура :)
> Позволят применить к рабочей копии патч в формате unidiff.
тоже круто.
ура :)
> Позволят применить к рабочей копии патч в формате unidiff.
тоже круто.
>>Только одна папка .svn в корне
Моя мечта сбылась.
Моя мечта сбылась.
я пользуюсь
к сожелению не приходилось, но возможно в ближайшем будущем, если команда решит, будем пробовать :)
я вот понять не могу, что ж такого в этом git или mercurial?
В SVN тоже можно работать, пока лежит сервер.
Все равно, и там и там необходимо потом мержить то, что написано.
Все равно, и там и там необходимо потом мержить то, что написано.
Git/Hg уменьшают количество шагов, которые нужно сделать. Понятно, что в SVN можно сделать всё, что умеют Git/Hg: настроить локальное зеркало удаленного репозитория, делать и мерджить бранчи, но в Git/Hg это просто удобнее. Можно работать над какой-то фичей, а если срочно что-то нужно поправить в текущей версии, но фича ещё не готова, просто делаешь update к соответствующему changeset, исправляешь, комитишь, делаешь update к своей работе, продолжаешь работать, и это всё делается очень быстро и просто.
Больше 10 лет работали с CVS и SVN, потом пару лет на Git, но в конце-концов не выдержали — когда история накопилась, он стал дико тормозным (наверное потому что у нас Windows?), перешли на Fossil (http://fossil-scm.org/) — компактно, быстро, всё-в-одном.
Почему меньше, наоборот больше: сначала надо сделать коммит к себе, а потом push на удаленный репозиторий. А в svn сразу на сервер. Так что Вы лукавите…
Я на прошлой неделе ругался, когда с сервером svn что-то происзходило, а мне надо было вытащить 1 сраный файл из прошлой ревизии. При пользовании git-ом на других проектах таки проблем небыло никогда.
А как вытянуть 1 файл в гите при неработающем сервере? Откуда его взять? Он же должен где-то храниться.
в локальном репе взять, или взять из репа другоко члена команды…
если он есть локально — я могу его скопировать вообще без системы контроля версий.
Вы очевидно не понимаете. Гит и другие децентрализированые системы контроля версий держат историю локально. Файла с предыдущей версии нету, но git/hg вам его с удовольтвием предоставлят на запрос без шуршания по сети.
ок, и как тогда получить последнюю версию файла? с последними изменениями, сделанными не мной?
git log --pretty=oneline path/to/file — видите историю изменений в данном файле. соответсвенно копируете себе хеш комита, который вам подходит.
потом делаете git checkout <хешкомита> path/to/file
и получаете нужную версию файла.
--pretty=oneline — формат отображения истории, таков для данной задачи наверное самый удобный.
потом делаете git checkout <хешкомита> path/to/file
и получаете нужную версию файла.
--pretty=oneline — формат отображения истории, таков для данной задачи наверное самый удобный.
Кхм…
> а мне надо было вытащить 1 сраный файл из прошлой ревизии
> прошлой
Все началось с небходимости посмотреть прошлую ревизию, закончилось «как получить последнюю вресию файла»
> а мне надо было вытащить 1 сраный файл из прошлой ревизии
> прошлой
Все началось с небходимости посмотреть прошлую ревизию, закончилось «как получить последнюю вресию файла»
У соседа по комнате
Где гарантия, что у него последняя версия?
А где гарантия, что на «централизованном» сервере последняя версия?
На сервере SVN всегда последняя закомиченная версия.
Как в Git/Hg держать актуальной рабочую копию при не работающем центральном (ну или каком-то корневом сервере в децентрализованной системе) сервере?
Как в Git/Hg держать актуальной рабочую копию при не работающем центральном (ну или каком-то корневом сервере в децентрализованной системе) сервере?
«Центральный» реп можно поднять вместе с коммитами и ветками из любой локальной копии.
Но возьмем, к примеру, случай, когда разработчик работает над некой фичей. Он работает в отдельной ветке, текущее состояние «центрального» репа ему ни к чему — у него своя задача. Предположим, падает этот самый «центральный» реп. Как дальше работать пользователю svn? Да никак — ждать, пока поднимут сервер, или копить коммит в пару мегабайт текста. Как дальше работать пользователю git? Как и раньше работал — о падении «центрального» репозитория он узнает только после того как доделает фичу, сольет ветку с ней в главную и попытается залить ее на упавший реп. И даже если до этого момента реп не починят, он пожмет плечами, создаст новую ветку и начнет работать над новой фичей.
Предположим, что пользователя snv вполне устраивает ситуация с коммитом в несколько мегабайт. Он продолжает дальше работать, не делая коммитов, и тут обнаруживает ошибку в главной ветке (которая влияет не только на его фичу, но и на все прочее). Ему нужно переключиться в центральную ветку, сделать фикс, переключиться обратно. А он не может этого сделать, т.к. репозиторий лежит. Что в этом случае сделает пользователь git? Переключится на главную ветку (она у него есть локально), сделает фикс, попытается пушнуть все это в центральный реп, скажет: «Ой, центральный реп лежит», переключится в свою рабочую ветку, смержит главную, и продолжит работать. А фиксы зальет на сервер тогда, когда его поднимут.
Но возьмем, к примеру, случай, когда разработчик работает над некой фичей. Он работает в отдельной ветке, текущее состояние «центрального» репа ему ни к чему — у него своя задача. Предположим, падает этот самый «центральный» реп. Как дальше работать пользователю svn? Да никак — ждать, пока поднимут сервер, или копить коммит в пару мегабайт текста. Как дальше работать пользователю git? Как и раньше работал — о падении «центрального» репозитория он узнает только после того как доделает фичу, сольет ветку с ней в главную и попытается залить ее на упавший реп. И даже если до этого момента реп не починят, он пожмет плечами, создаст новую ветку и начнет работать над новой фичей.
Предположим, что пользователя snv вполне устраивает ситуация с коммитом в несколько мегабайт. Он продолжает дальше работать, не делая коммитов, и тут обнаруживает ошибку в главной ветке (которая влияет не только на его фичу, но и на все прочее). Ему нужно переключиться в центральную ветку, сделать фикс, переключиться обратно. А он не может этого сделать, т.к. репозиторий лежит. Что в этом случае сделает пользователь git? Переключится на главную ветку (она у него есть локально), сделает фикс, попытается пушнуть все это в центральный реп, скажет: «Ой, центральный реп лежит», переключится в свою рабочую ветку, смержит главную, и продолжит работать. А фиксы зальет на сервер тогда, когда его поднимут.
Это все хорошо, но репозитории не то чтобы часто падают :). Учитывая что в Subversion есть довольно простая в настройке машинерия для создания резервного репозитория с синхронизацией каждого коммита.
Хм, возможно вы правы.
Единственное, не пойму, почему у всех такая проблема, как лежит сервер такая актуальная.
У нас за 4 года svn был недоступен лишь один раз, пол часа, когда обновлялись DNS.
Единственное, не пойму, почему у всех такая проблема, как лежит сервер такая актуальная.
У нас за 4 года svn был недоступен лишь один раз, пол часа, когда обновлялись DNS.
Да из банальных даже примеров: я работаю дома, упал интернет, или я забыл его оплатить. У меня завтра дэдлайн, и я пишу код в метро. Ну или просто из-за какой-нибудь неведомой ебаной фигни покрашился реп (для свн тут вообще катастрофа, не так ли?).
Но на самом деле, эта проблема сильно теоретическая. Гораздо более насущной является проблема переключения в другую ветку посреди коммита и внесения там изменений. У svn, насколько я знаю, аналога команды stash нет.
Но на самом деле, эта проблема сильно теоретическая. Гораздо более насущной является проблема переключения в другую ветку посреди коммита и внесения там изменений. У svn, насколько я знаю, аналога команды stash нет.
И какая польза проекту от такого коммита в метро? Кто им может воспользоваться?
Покрашился реп? Ну, обычные регулярные бекапы (даже бекап на коммит) никто не отменял, с таким успехом — какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?
Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать:
svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
svn switch SOME_BRANCH
svn commit -m «work in progress»
svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE
А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль.
Опять же, если есть необходимость править несколько веток одновременно, которые нужны только мне самому и локально… хм, зачем тут система контроля версий для коллективной разработки?
Покрашился реп? Ну, обычные регулярные бекапы (даже бекап на коммит) никто не отменял, с таким успехом — какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?
Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать:
svn copy CURRENT_URL_OF_WORKING_COPY SOME_BRANCH
svn switch SOME_BRANCH
svn commit -m «work in progress»
svn switch WHATEVER_I_WAS_WORKING_ON_BEFORE
А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль.
Опять же, если есть необходимость править несколько веток одновременно, которые нужны только мне самому и локально… хм, зачем тут система контроля версий для коллективной разработки?
>И какая польза проекту от такого коммита в метро? Кто им может воспользоваться?
Я выйду из метро, дойду до интернета и запушу все в центральный реп. При этом у меня с собой в метро будут все ветки, и я смогу нормально коммитить, а не набирать гигантских размеров коммит.
> какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?
Все разработчики в сумме держат полную и атуальную версию репа. Восстанавливаем «центральный» реп из локального от любого автора, отсальные делают в него пуш — вуаля, полностью актуальный реп со всеми коммитами.
>Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать:
Я говорил не об этом. Предположим, вы делаете некоторую фичу и обнаруживаете баг в главной ветке. Вам нужно переключиться в главную ветку и поправить этот баг. Но у вас есть незакоммиченные изменения, которые коммитить сейчас нельзя, т.к. код банально не дописан и не проверен. В git вы делаете stash, переключаете ветку, делаете фикс, переключаетесь обратно, делаете stash apply. Как вы разрулите это в svn.
>А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль.
Этот коммит зальется в центральный реп, как только оный станет доступен. И это могут быть несколько красивых коммитов, а не один толстый с тучей правок.
Я вижу, что вы не совсем понимаете или совсем не понимаете смысл работы в ветках…
Я выйду из метро, дойду до интернета и запушу все в центральный реп. При этом у меня с собой в метро будут все ветки, и я смогу нормально коммитить, а не набирать гигантских размеров коммит.
> какая гарантия, что кто-то «второй» держит у себя полную копию git/hg репозитария?
Все разработчики в сумме держат полную и атуальную версию репа. Восстанавливаем «центральный» реп из локального от любого автора, отсальные делают в него пуш — вуаля, полностью актуальный реп со всеми коммитами.
>Аналога команды stash нет, но если нужно поправить другую ветку, почему нельзя сделать:
Я говорил не об этом. Предположим, вы делаете некоторую фичу и обнаруживаете баг в главной ветке. Вам нужно переключиться в главную ветку и поправить этот баг. Но у вас есть незакоммиченные изменения, которые коммитить сейчас нельзя, т.к. код банально не дописан и не проверен. В git вы делаете stash, переключаете ветку, делаете фикс, переключаетесь обратно, делаете stash apply. Как вы разрулите это в svn.
>А если, как говорят многие пользователи git/hg, сервер недоступен/лежит, то и смысла от этого коммита для проекта — ноль.
Этот коммит зальется в центральный реп, как только оный станет доступен. И это могут быть несколько красивых коммитов, а не один толстый с тучей правок.
Я вижу, что вы не совсем понимаете или совсем не понимаете смысл работы в ветках…
> Как вы разрулите это в svn.
Создам еще одну рабочую копию.
> И это могут быть несколько красивых коммитов
В svn это может быть несколько рабочих копий => несколько коммитов (менее удобно, но все же).
Создам еще одну рабочую копию.
> И это могут быть несколько красивых коммитов
В svn это может быть несколько рабочих копий => несколько коммитов (менее удобно, но все же).
Это называется «извращения», это уже о другом…
Если сервер лежит при этом (невозможно сделать checkout), то просто скопирую рабочую копию, откачу в ней все изменения, и внесу нужные исправления.
> «извращения»
Скорее особенности, но основной смысл в том, что и с svn можно некоторое время работать без связи с сервером.
Для мелких изменений (поправить один файл) в svn создавать отдельную глобальную ветку нецелесообразно, гораздо проще ограничиться еще одной рабочей копией (в этом случае её можно сравнить с локальными ветками в гите).
> «извращения»
Скорее особенности, но основной смысл в том, что и с svn можно некоторое время работать без связи с сервером.
Для мелких изменений (поправить один файл) в svn создавать отдельную глобальную ветку нецелесообразно, гораздо проще ограничиться еще одной рабочей копией (в этом случае её можно сравнить с локальными ветками в гите).
>Если сервер лежит при этом (невозможно сделать checkout), то просто скопирую рабочую копию, откачу в ней все изменения, и внесу нужные исправления.
И как потом эти внесенные изменения потом перенести в вашу рабочую копию? Вы совершенно не поняли, о чем я. И непонимание это кроется именно в особенностях работы с svn. Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки. В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию. Да и вообще создание второй рабочей копии выглядит как извращение, откровенно говоря, в любом случае.
И как потом эти внесенные изменения потом перенести в вашу рабочую копию? Вы совершенно не поняли, о чем я. И непонимание это кроется именно в особенностях работы с svn. Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки. В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию. Да и вообще создание второй рабочей копии выглядит как извращение, откровенно говоря, в любом случае.
> И как потом эти внесенные изменения потом перенести в вашу рабочую копию?
Будет 2 рабочие копии, основанные на одной ревизии: (1) основная, (2) фикс. Коммитим (2), обновляем (1), коммитим (1), удаляем (2), если не нужен.
> Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки.
В этом случае у него просто будет 2 рабочих копии (или больше если фич много). В конечном счете они все вольются в trunk и, возможно, будут удалены из репозитория. Неудобно, если фич много, но часто ли один разработчик параллельно разрабатывает много фич? ИМХО, 2-3-4 рабочих копии вполне нормально.
> В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию.
Нет, не извращение — особенность. Я ведь тоже могу сказать, что полностью извлекать себе весь репозиторий ради исправления одной строки в одном файле — это извращение…
Будет 2 рабочие копии, основанные на одной ревизии: (1) основная, (2) фикс. Коммитим (2), обновляем (1), коммитим (1), удаляем (2), если не нужен.
> Я говорю о ситуации (довольно стандартной для git), когда разработчик разрабатывает фичу в отдельной ветке, чтобы не засорять develop или master ветки.
В этом случае у него просто будет 2 рабочих копии (или больше если фич много). В конечном счете они все вольются в trunk и, возможно, будут удалены из репозитория. Неудобно, если фич много, но часто ли один разработчик параллельно разрабатывает много фич? ИМХО, 2-3-4 рабочих копии вполне нормально.
> В таком случае ваш план выглядит именно как извращение — ради правки в другой ветке создавать отдельную рабочую копию.
Нет, не извращение — особенность. Я ведь тоже могу сказать, что полностью извлекать себе весь репозиторий ради исправления одной строки в одном файле — это извращение…
Вы опять не поняли ситуацию…
Вы разрабатываете фичу. Делаете это в отдельной ветке. В этой фиче у вас уже сделано несколько коммитов, которых еще нет в главной ветке. И тут в главной ветке вы замечаете ошибку. Ошибка мешает вашей дальнейшей разработке. ее нужно поправить. Но править в вашей рабочей ветке нельзя, т.е. этот фикс не попадет в мастер-ветку до окончания разработки фичи, а значит не попадет и к остальным разработчикам и в релиз (если он состоится до завершения разработки фичи).
Я говорю с вами и натыкаюсь на стену непонимания. Вы, судя по всему, совершенно не понимаете принципов работы в ветках или принципов работы git`а…
Вы разрабатываете фичу. Делаете это в отдельной ветке. В этой фиче у вас уже сделано несколько коммитов, которых еще нет в главной ветке. И тут в главной ветке вы замечаете ошибку. Ошибка мешает вашей дальнейшей разработке. ее нужно поправить. Но править в вашей рабочей ветке нельзя, т.е. этот фикс не попадет в мастер-ветку до окончания разработки фичи, а значит не попадет и к остальным разработчикам и в релиз (если он состоится до завершения разработки фичи).
Я говорю с вами и натыкаюсь на стену непонимания. Вы, судя по всему, совершенно не понимаете принципов работы в ветках или принципов работы git`а…
И что делать, если кто-то сломает мои «несколько красивых коммитов» по середине своей цепочкой из ста коммитов?
Все зависит от админов и надежности связи, у нас часто бывало, что svn или tfs недоступны и работать или просто трудно, или невозможно…
Это да, пока все работающие сидят в одной комнате.
Как только они начинают перемещаться по шарику, оказываться в местах где интернет через gprs и эпизодически, git становится сильно лучше.
Как только они начинают перемещаться по шарику, оказываться в местах где интернет через gprs и эпизодически, git становится сильно лучше.
Похоже, что понять всю силу и преимущество git можно только если наш svn-сервер будет постоянна падать. За последние 3 года, у нас такого не было ни разу. Все эти примеры из разряда: а что вы будите делать, если вам комп накроется? Сидеть и ждать?! А пользователь git сделает brache и продолжит работу! :)))
Вот удобство использования в повседневной работе, простота merge-й — это да, есть над чем задуматься.
Вот удобство использования в повседневной работе, простота merge-й — это да, есть над чем задуматься.
На самом деле да, возможность работы без центрального сервера лично для меня далеко не самая главная причина перехода с svn.
Основные причины:
1) Лучшая защита от дурака. C git гораздо сложнее забыть добавить файл в индекс или потерять свои изменения. Однажды в svn во время мерджа по ошибке ввел tf вместо mf — потерял довольно большой кусок кода, восстановить не смог (да, я знаю, что я сам криворукий дебил и меня к компьютеру вообще подпускать нельзя). В git же на момент pull все локальные изменения всегда закоммичены и их всегда можно восстановить.
2) Более удобная работа с ветками. Про это уже сказали
3) git stash. Тоже упоминался
4) git автоматически распознает переименования, перемещения и удаления файлов в ФС без использования собственных комманд
5) github
6) Быстрый просмотр истории, переключение между ветками, чекаут отдельных ревизий — не нужно идти за этим на сервер
7) Более чистая рабочая директория. Нет отдельных папок для веток и тегов, всего одна папка .git (рад что в .svn теперь также)
Основные причины:
1) Лучшая защита от дурака. C git гораздо сложнее забыть добавить файл в индекс или потерять свои изменения. Однажды в svn во время мерджа по ошибке ввел tf вместо mf — потерял довольно большой кусок кода, восстановить не смог (да, я знаю, что я сам криворукий дебил и меня к компьютеру вообще подпускать нельзя). В git же на момент pull все локальные изменения всегда закоммичены и их всегда можно восстановить.
2) Более удобная работа с ветками. Про это уже сказали
3) git stash. Тоже упоминался
4) git автоматически распознает переименования, перемещения и удаления файлов в ФС без использования собственных комманд
5) github
6) Быстрый просмотр истории, переключение между ветками, чекаут отдельных ревизий — не нужно идти за этим на сервер
7) Более чистая рабочая директория. Нет отдельных папок для веток и тегов, всего одна папка .git (рад что в .svn теперь также)
Понять всю силу и преимущество git можно только если вы им попользуетесь. За последний год когда я пользовался Git, я ни разу не смотрел в сторону svn.
Единственно когда Git не работает — это большие репозитории, когда размер истории больше чем несколько гигабайт.
Единственно когда Git не работает — это большие репозитории, когда размер истории больше чем несколько гигабайт.
> На сервере SVN всегда последняя закомиченная версия.
Согласен. Но если сервер не работает, то Вы этот файл и не получите, кроме как простым копированием. А если вам надо много файлов? А если вам надо целый коммит соседа? Как вы без центрального сервера обменяетесь историей при использовании SVN?
А с git/hg ситуация иная. Последней версии файла вообще не существует, как и понятия актуальной рабочей копии. Последняя закомиченная версия есть только в конкретном репозитории.
Согласен. Но если сервер не работает, то Вы этот файл и не получите, кроме как простым копированием. А если вам надо много файлов? А если вам надо целый коммит соседа? Как вы без центрального сервера обменяетесь историей при использовании SVN?
А с git/hg ситуация иная. Последней версии файла вообще не существует, как и понятия актуальной рабочей копии. Последняя закомиченная версия есть только в конкретном репозитории.
> Последней версии файла вообще не существует
А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит свои фичи… что-то тут не то.
А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит свои фичи… что-то тут не то.
Два человека правили один файл. Оба сделали коммиты. Вопрос: у кого из них в репозитории файл последней версии?
Вы не путаете репозитарий и рабочую копию?
Если они правили пересекающиеся места — второй не сможет закомитить, прийдется сперва сделать апдейт, потом смержить и закомитить.
Первому тоже, чтобы обновить рабочую копию необходимо сделать update.
В любом случае, перед началом работы необходимо делать update, независимо, какой системой контроля пользоваться.
Если они правили пересекающиеся места — второй не сможет закомитить, прийдется сперва сделать апдейт, потом смержить и закомитить.
Первому тоже, чтобы обновить рабочую копию необходимо сделать update.
В любом случае, перед началом работы необходимо делать update, независимо, какой системой контроля пользоваться.
Вы говорите о SVN, а я про Git/Hg. В Git/Hg я могу сделать хоть сотню коммитов. Проблема возникнет только тогда, когда они попытаются обновить историю на одном и том же сервере с помощью push.
В Git/Mercurial каждая рабочая копия и есть полноценный репозитарий. Потому два разработчика могут спокойно обмениваться коммитами без какого-либо центрального сервера.
Что касается ответа на вопрос:
> А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит
> свои фичи… что-то тут не то.
Вы представляете как устроен процесс разработки, например, ядра Linux? Упрощённо это происходит так. Есть много разработчиков, которые пишут код, фиксят баги. Потом полученные коммиты присылаются людям, отвественным за определённые области в ядре. После review, тестов и прочего ответственные включают или не включают конкретные коммиты в свои основные бранчи. И уже после этого Торвалдс выбирает нужные коммиты из репозиториев этих ответственных за подсистемы и включает в свою основную ветвь. В определённый момент принимается решение и выпускается новая версия ядра.
В итоге что имеем: нет никакого центрального репозитория, копошится куча народу, каждый в своей песочнице. Но тем не менее. Релиз ядра — это просто состояние основной ветки в репозитории Линуса Торвалдса в определённый момент времени.
Так что и с любым другим проектом — просто конкретный репозиторий (например, репозиторий тимлида) мы объявляем центральным и из него берём код для релизов.
P.S. На самом деле часто центральными репами являются bare repos, но сути это не меняет.
Что касается ответа на вопрос:
> А что релизить-то будем? Каждый ковыряется в своей песочнице, лепит
> свои фичи… что-то тут не то.
Вы представляете как устроен процесс разработки, например, ядра Linux? Упрощённо это происходит так. Есть много разработчиков, которые пишут код, фиксят баги. Потом полученные коммиты присылаются людям, отвественным за определённые области в ядре. После review, тестов и прочего ответственные включают или не включают конкретные коммиты в свои основные бранчи. И уже после этого Торвалдс выбирает нужные коммиты из репозиториев этих ответственных за подсистемы и включает в свою основную ветвь. В определённый момент принимается решение и выпускается новая версия ядра.
В итоге что имеем: нет никакого центрального репозитория, копошится куча народу, каждый в своей песочнице. Но тем не менее. Релиз ядра — это просто состояние основной ветки в репозитории Линуса Торвалдса в определённый момент времени.
Так что и с любым другим проектом — просто конкретный репозиторий (например, репозиторий тимлида) мы объявляем центральным и из него берём код для релизов.
P.S. На самом деле часто центральными репами являются bare repos, но сути это не меняет.
В том то и кайф децентрализации — все изменения доступны локально.
git checkout… — и все.
git checkout… — и все.
В git нет понятия сервера. У каждого из членов команды есть своя копия всего репозитория. Некоторые локальные ветки могут ссылатся на ветки на удаленных машинах, но все операции (коммиты, просмотр истории, ветвления и слияния — все кроме синхронизации локальных и удаленных веток) выполняются с локальным репозиторием
Отлично. А мне-то от Системы Контроля Версий только синхронизация и нужна была…
Если вы:
1) Никогда не просматриваете историю изменений
2) Не пользуетесь ветками
3) Никогда не откатываете свои или чужие изменения
то вам и система контроля версий-то в принципе не нужна. Хватит и diff+patch. Но я что-то сомневаюсь, что вам действительно нужна только синхронизация
1) Никогда не просматриваете историю изменений
2) Не пользуетесь ветками
3) Никогда не откатываете свои или чужие изменения
то вам и система контроля версий-то в принципе не нужна. Хватит и diff+patch. Но я что-то сомневаюсь, что вам действительно нужна только синхронизация
1) Без синхронизации с сервером локальная история изменений меня не интересует.
2) Использую, когда это необходимо
3) Откатываю.
2) Использую, когда это необходимо
3) Откатываю.
1) У вас есть не только локальная история (ваши изменения) но и полная история всех изменений до времени последнего pullа. Чтобы посмотреть историю, вам не надо обращаться к центральному серверу, вся история есть уже у вас на машине. Просмотр истории в git/hg банально быстрее.
1-2-3) Выясняется, что не только синхронизация нужна
Да и в целом по поводу синхронизации. Если у вас по каким-то причинам нет доступа к центральному svn-серверу, у вас нет никакой возможности передать код коллегам. В git же вы в таком случае можете добавить репозиторий своего коллеги себе как remote и синхронизироваться напрямую с ним.
1-2-3) Выясняется, что не только синхронизация нужна
Да и в целом по поводу синхронизации. Если у вас по каким-то причинам нет доступа к центральному svn-серверу, у вас нет никакой возможности передать код коллегам. В git же вы в таком случае можете добавить репозиторий своего коллеги себе как remote и синхронизироваться напрямую с ним.
Каждому своё. git хорош для стартапов, небольших комманд, опен-соурса. А вот например в мире больших корпораций мысль о том что исходники могут быть «размазаны» по большому числу компьютеров, а не храниться централизовано на сервере — вызывает панику. Потому здесь лучше прижились svn и TFS.
Странный аргумент. По пачке рабочих копий на разных машинах — это не «размазаны»? Или Вы об отсутствии центрального сервера? Так его можно поставить и для Гита/Меркуриала, какие проблемы…
Разные механизмы работы. При централизованных системах все исходники всегда на центральном сервере. При этом ни один программист не может надолго «уйти в подвал» или работать с каким-то своим локальным репозиторием. Все стараются почаще комититься\апдейтиться.
В результате:
-в одном месте видно кто и что сделал
-в любой момент можно уволить кого-угодно — много кода не пропадёт.
-можно легко пережить «смерть» любого рабочего компьютера (а в больших коммандах это бывает часто)
-удобно принимать административные решения типа «на эту ветку мы забьём, а эти две сольём»
-легко кому-то запретить доступ куда-то
Центральный сервер Гита решает проблему только частично. Им можно пользоваться, а можно и забить, даже если он есть :) — тут уж чисто административные меры можно принимать для борьбы с этим.
В результате:
-в одном месте видно кто и что сделал
-в любой момент можно уволить кого-угодно — много кода не пропадёт.
-можно легко пережить «смерть» любого рабочего компьютера (а в больших коммандах это бывает часто)
-удобно принимать административные решения типа «на эту ветку мы забьём, а эти две сольём»
-легко кому-то запретить доступ куда-то
Центральный сервер Гита решает проблему только частично. Им можно пользоваться, а можно и забить, даже если он есть :) — тут уж чисто административные меры можно принимать для борьбы с этим.
Все это какие-то не менее странные подробности.
Результатом работы программиста является не ченж-лист, а закрытый таск — тот факт, что промежуточные коммиты хранятся на их машинах, а не на центральном сервере, не является проблемой, т.к. это всего лишь кусочек выполнения таска, который в таком виде никому не нужен.
Кто и что сделал так же оценивается по закрытым таскам, а не по числу коммитов. Да и что это за метрика такая: человек, который на таск делает 100 коммитов продуктивнее, чем тот, кто делает один?
Т.к. таски при нормальном режиме работы редко длятся больше двух дней, а на рабочих машинах у многих стоит рейд, то потеря данных в результате смерти машины — достаточно минорный риск: не больший по затратам времени и сил, чем, собственно, замена рабочей машины.
При наличии центрального репо ветки так же поддаются контролю.
Неудобство запрета доступа на конкретные части проекта — да, это недостаток вышеупомянутых систем, но к размазанности он относится слабо по-моему.
Ну и наконец, нет, Вы не можете уволить кого-угодно в любой момент, на это нужен месяц, а за это время можно без проблем залить недостающие изменения куда-либо.
Результатом работы программиста является не ченж-лист, а закрытый таск — тот факт, что промежуточные коммиты хранятся на их машинах, а не на центральном сервере, не является проблемой, т.к. это всего лишь кусочек выполнения таска, который в таком виде никому не нужен.
Кто и что сделал так же оценивается по закрытым таскам, а не по числу коммитов. Да и что это за метрика такая: человек, который на таск делает 100 коммитов продуктивнее, чем тот, кто делает один?
Т.к. таски при нормальном режиме работы редко длятся больше двух дней, а на рабочих машинах у многих стоит рейд, то потеря данных в результате смерти машины — достаточно минорный риск: не больший по затратам времени и сил, чем, собственно, замена рабочей машины.
При наличии центрального репо ветки так же поддаются контролю.
Неудобство запрета доступа на конкретные части проекта — да, это недостаток вышеупомянутых систем, но к размазанности он относится слабо по-моему.
Ну и наконец, нет, Вы не можете уволить кого-угодно в любой момент, на это нужен месяц, а за это время можно без проблем залить недостающие изменения куда-либо.
Я не буду продолжать спор так как не очень много работал с децентрализованными системами. Может быть Вы и правы, а я чего-то не понимаю.
Но вот Вы знаете много крупных (от нескольких десятков человек и выше) IT-фирм, использующих штатно git\mercurial, а не что-то централизованное? Вот в радиусе моей видимости соотношение где-то 10:1 в пользу svn\tfs. Не знаю, может случайность такая. Но мне кажется, что в большой фирме степень бардака и так большая а еще и увеличивать её исходниками, разбросанными по разным компьютерам — себе дороже.
Но вот Вы знаете много крупных (от нескольких десятков человек и выше) IT-фирм, использующих штатно git\mercurial, а не что-то централизованное? Вот в радиусе моей видимости соотношение где-то 10:1 в пользу svn\tfs. Не знаю, может случайность такая. Но мне кажется, что в большой фирме степень бардака и так большая а еще и увеличивать её исходниками, разбросанными по разным компьютерам — себе дороже.
Я знаю фирмы, где используется не Svn, где Svn комбинируется с другими системами (Git или Mercurial). Но оглянитесь: некоторые фирмы до сих пор используют CC, VSS и CVS. Крупные IT-фирмы на то и крупные, чтобы плестись в хвосте эволюции — у них стоимость внедрения новых решений куда выше, чем у средних и мелких — а ресурсы точно так же выжимаются по максимуму, и найти силы на общий переход, да еще и со спорными преимуществами, бывает просто невозможно.
Я ни в коей мере не пытаюсь в этом споре доказать, что Svn хуже (ниже я написал немало комментариев как в его защиту, так и против него), но ожидать, что мерилом его устарелости будут ведущие игроки рынка точно не приходится — им просто не интересно и не выгодно проверять на себе новые решения.
Я ни в коей мере не пытаюсь в этом споре доказать, что Svn хуже (ниже я написал немало комментариев как в его защиту, так и против него), но ожидать, что мерилом его устарелости будут ведущие игроки рынка точно не приходится — им просто не интересно и не выгодно проверять на себе новые решения.
>Каждому своё. git хорош для стартапов, небольших комманд, опен-соурса.
ядро линукса или самба это стартапы с маленькой командой?
ядро линукса или самба это стартапы с маленькой командой?
Есть «центральный» репозиторий, в котором хранятся результаты работы всех авторов. Есть локальные репозитории у каждого из авторов, которые отличаются от центрального только наличием изменений и веток, необходимых в данный момент только этому автору (например, фича, над которой работает только он). В случае необходимости это все сливается в «центральный» реп. Где тут размазанность?
Более того — при падении «центрального» репозитория его можно будет восстановить вместе с коммитами и ветками из локальной копии любого автора. А авторы смогут спокойно работать даже при упавшей сети или умершем «централном» репозитории, не делая вообще никаких дополнительных действий.
«Центральный» я пишу в кавычках, потому что у git такого понятия нет. Есть удаленные репозитории, коих к локальному можно подключить хоть сто.
Более того — при падении «центрального» репозитория его можно будет восстановить вместе с коммитами и ветками из локальной копии любого автора. А авторы смогут спокойно работать даже при упавшей сети или умершем «централном» репозитории, не делая вообще никаких дополнительных действий.
«Центральный» я пишу в кавычках, потому что у git такого понятия нет. Есть удаленные репозитории, коих к локальному можно подключить хоть сто.
А еще есть менеджер, который должен понимать кто что делает и в каком состоянии текущая задача каждого человека. А ну ка расскажите, как это сделать в децентрализованной системе? Без центрального сервера — вообще никак. С ним — только с определенной степенью точности — «Вася 3 дня назад закончил задачу такую-то, а щас хрен-его знает чем занимается».
Что-что? Спрашивать устно и верить людям на слово? :)
Что-что? Спрашивать устно и верить людям на слово? :)
Если в команде такие разработчики, за которыми нужен глаз да глаз, можно все ветки в конце дня (например) пушить в «центральный» репозиторий.
А еще лучше — уволить таких разработчиков к чертям.
А заодно с ними и менеджера, который считает наличие коммитов, содержимое которых он все равно не в состоянии понять, признаком прогресса по поставленной задаче :)
Ну, менеджера, который не в состоянии понять содержание коммита в любом случае стоит гнать, независимо от используемой системы управления версиями. Речь о том, что в централизованной системе у менеджера хотя бы есть возможность эти коммиты видеть в реал-тайме. Вот бывает ставит заказчик задачу: ускорить быстродействие на 400%. При децентрализованной системе работы эта задача уйдет программеру и он её не пушнет на центральный сервак, пока не выполнит полностью (пусть это займет 4 дня). В централизованной — за 4 дня может быть сделано 20 коммитов с комментами типа «добавлено кеширование +20%», «оптимизированы запросы к базе +60%». В итоге если заказчик на второй день спросит как дела, менеджер с централизованной системой скажет — уже стало на 80% лучше, можете взять текущий билд проверить, а мы продолжаем работать. Менеджер децентрализованной может ответить только «хз, ща пойду спрошу, показать пока нечего».
Извините, но я все равно Вас не понимаю. Вы говорите, что централизация заставит сотрудников заливать код раз в день и чаще на центральный сервер? Нет, не заставит. Всегда найдутся люди, которые копят ченжи и выкладывают по завершении таска — это вопрос баланса между комфортом программиста и требованиями решаемой задачи. Если Вам нужны итеративные улучшения, если есть возможность этот итеративный прогресс подтверждать тестами, то просто попросите человека выкладывать почаще — и не важно, какая при этом у вас используется система, это не вопрос техпроцесса совершенно.
Могу сказать за крупные канадские телекомуникационные компании — все поголовно юзают ClearCase (а «обломки» Нортела юзают нортеловские костыли над clearcase под названием NEU)
Скажите, а как в такому случае владельцами коммитов управлять?
Вот допустим, я в свой реп код кладу как Вася, и мой друг Вася тоже с таким же именем. Как нам потом разобраться, кто что коммитил?
Вот допустим, я в свой реп код кладу как Вася, и мой друг Вася тоже с таким же именем. Как нам потом разобраться, кто что коммитил?
git config user.name «Vasya Ivanov»
git config user.email «vasyaivanov@ivanovs.com»
Не работает, если вы полные тезки с одним email-адресом на двоих
git config user.email «vasyaivanov@ivanovs.com»
Не работает, если вы полные тезки с одним email-адресом на двоих
А конфиги то где? Каждый сам себе админ получается?
Если доступ к главному репозиторию через ssh, то вы можете отличать пользователей по публичным ключам.
А без ssh эту проблему не решить?
Доступ к удаленному git репозиторию выполняется тремя способами:
1) По HTTP. В основном используется для read-only доступа. Push делать можно, но это не удобно. В этом случае можете различать пользователей по имени/паролю или любым другим удобным способом для HTTP-авторизации;
2) Собственный протокол git:// — только read-only;
3) ssh — в 99% случаев используется для read-write доступа, идентификацировать пользователей можно по имени/паролю или публичному ключу.
1) По HTTP. В основном используется для read-only доступа. Push делать можно, но это не удобно. В этом случае можете различать пользователей по имени/паролю или любым другим удобным способом для HTTP-авторизации;
2) Собственный протокол git:// — только read-only;
3) ssh — в 99% случаев используется для read-write доступа, идентификацировать пользователей можно по имени/паролю или публичному ключу.
Топором. Отрубать пальцы тем, кто ставит одинаковые имена пользователей и почту.
Встречный вопрос, а как вообще идентифицируются пользователи в SVN (давно это было, не помню).
Встречный вопрос, а как вообще идентифицируются пользователи в SVN (давно это было, не помню).
Когда создаёшь реп, в конфиге эту инфу указываешь.
Дело не в одинаковых именах и почтах, а в том, что пользователь сам это может настраивать, и администратор не может это контролировать.
Дело не в одинаковых именах и почтах, а в том, что пользователь сам это может настраивать, и администратор не может это контролировать.
Когда речь идет о центральном сервере (svn, или git/hg+shh) — тут можно что-то контролировать, а когда такого сервера нет — то невозможно. Само понятие децентрализованности предполагает отсутствие такого центрального контролирующего админа.
Да, спасибо.
Для меня вот собственно, это и является основным сдерживающим фактором, для перехода на git/hg.
Для меня вот собственно, это и является основным сдерживающим фактором, для перехода на git/hg.
Но я так и не понял проблемы… Проблема в том, что пользователь может назначить себе любое имя? Или в чем? Отказываться из-за этого от всех прелестей git/hg как-то глупо что ли…
В том числи и в этом.
А что за прелести git/hg такие?
А что за прелести git/hg такие?
Ой, перечитайте уже комменты, лень в сотый раз писать…
Тогда почитайте и мои, где я писал, что прелести такие не нужны, а добавляют только хлопот.
Делается «центральный» репозиторий, и на нем настраиваются права кто что где может делать, если пользователь поставил левое имя, ему просто не получится что-то сделать… Например в mercurial есть расширение acl для этого, про git не знаю, не пользовался…
Спасибо, посмотрим, как будет время.
Но, что тогда остаётся от фишек hg/git? Ведь в случае с центральным репом получается, тот же svn нет?
Но, что тогда остаётся от фишек hg/git? Ведь в случае с центральным репом получается, тот же svn нет?
Вопрос вот в чем. Центральный сервер лишь ограничит число тех, кто на нем сможет изменять историю.
А как вычислить того, кто что-то нехорошее закоммитил и при этом представился, как Вася Пупкин с несуществующим ящиком?
А как вычислить того, кто что-то нехорошее закоммитил и при этом представился, как Вася Пупкин с несуществующим ящиком?
Выше писали про плагин acl, который позволяет отличать пользователей по публичным ключам.
Но тогда другой вопрос, если система децентрализованная, ведь злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно, а валидный пользователь сможет его уже в реп положить.
Но тогда другой вопрос, если система децентрализованная, ведь злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно, а валидный пользователь сможет его уже в реп положить.
Извините, эта уже какая-то совсем надуманная проблема. Кто вас заставляет шарить локальные репозитории дальше личного компьютера? Такими темпами мы дойдем до того, что гит небезапасасен, потому что злоумышленник может с компьютера валидного пользователя коммитить пока тот покурить вышел
Ага, вырубив его при этом топором по голове.
Мне как администратора хранилища кода, важно видеть ответственного за каждую строчку кода, вот я и пытаюсь понять, как контролировать процесс коммитов в центральный реп.
Мне как администратора хранилища кода, важно видеть ответственного за каждую строчку кода, вот я и пытаюсь понять, как контролировать процесс коммитов в центральный реп.
Вам уже говорили, есть ssh-ключи, есть различные методы авторизации.
Дело в том что git-репозиторий, в отличие от svn — это не какой-либо серверный процесс, это просто директория на диске с определенной структурой. Если у злоумышленника нет доступа к этой директории коммитить он туда не сможет. Так что проблема «злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно» довольно таки сомнительная. А для центрального репозитория вам несколько решений уже показали
Дело в том что git-репозиторий, в отличие от svn — это не какой-либо серверный процесс, это просто директория на диске с определенной структурой. Если у злоумышленника нет доступа к этой директории коммитить он туда не сможет. Так что проблема «злоумышленник может любому валидному пользователю закомитить в его реп код от имени кого угодно» довольно таки сомнительная. А для центрального репозитория вам несколько решений уже показали
Для этого используется система контроля доступа к общему репозиторию. Например Gerrit это может делать. Пользователь побавляет свое имя и публичный ключ на сервер и когда следующий раз коммитишь — Gerrit проверяет что твой ключ валиден.
У SVN есть свои собственные учетки.
А часто 'коннект' лежит?
Ветки в subversion абсолютно неюзабельные из-за тупого механизма merge. В пше проблем с этим практически не было. Правда пше значительно сложнее в освоении. Все эти rebase, stash изрядно разрывают мозг.
Это актуально для версии 1.5. Начиная с 1.6 механизм merge починили, и для большинства сценариев он не отличается от такового для git.
Активно пользуюсь гитом уже 1.5-2 года (с использованием нескольких веток): rebase не юзал. И кстати, младшего программера-линускоида знающего svn заставил использовать git — он уже через 2-3 дня стабильно с ним работал.
Для меня, например, решающим фактором при переходе на Меркуриал стала скорость работы и удобная gui-оболочка.
Ниже есть разбивка по регионам, странный какой то тренд у Tурции — кто то знает почему так???
Посмотрел. Вижу, что гугл следит за ботинками blogs.timeslive.co.za/soccer/2010/02/25/another-mercurial-boot-from-nike/
В вашем графике шкалят запросы с турции, где как выясняется git=ходить. :)
Есть такая штука — git-svn. Создаешь git-репозиторий на основе svn-репа (он автоматом добавляется как удаленный) и работаешь. И сам счастлив, и команда дальше копошится в этом своем svn. Я так некоторое время работал — впечатления отличные.
Пробовали.
Только вопрос зачем на него переходить, если нас устраивает svn, остался нерешённым.
Только вопрос зачем на него переходить, если нас устраивает svn, остался нерешённым.
Можно хотя-бы попробовать и сравнить. Там чудовищная разница в скорости работы. После гита работать на свне — пытка.
Пробовал меркуриал, и немного гит.
А в чём скорость то выражается?
А в чём скорость то выражается?
Вы ветки используете? Один не докомитил и вся команда ждет? Или один забажил — другие также ждут фикса? Вот для этого git — все изолированно. Ну и редактирование текста комита — не радость ли? :)
Все всё пробовали. Только всегда всё в конечном итоге сводится к тому, что всё равно есть некий центральный репозиторий, куда все пушат свои изменения. Поэтому децентрализованность выливается по сути только в то, что есть возможность локально коммитить и откатываться, если что-то поломал.
Про прочие удовольствия (сейчас я говорю только про гит) вообще молчу. Гитовские сабмодули — тихий ужас по сравнению с svn externals. Все превозносимые фичи по работе с ветками (типа «как что-то понадобилось, сделал git branch и правишь изменения уже в новой ветке!») разом пропадают, если у нас есть build-каталог внутри дерева.
Про прочие удовольствия (сейчас я говорю только про гит) вообще молчу. Гитовские сабмодули — тихий ужас по сравнению с svn externals. Все превозносимые фичи по работе с ветками (типа «как что-то понадобилось, сделал git branch и правишь изменения уже в новой ветке!») разом пропадают, если у нас есть build-каталог внутри дерева.
Поясните последнюю фразу, пожалуйста. Почему бы build-каталог не заигнорить?
Потому что, например, при работе с CMake, имя билд-каталога может быть произвольным. Кто-то собирает в build, кто-то в Build, а debian вообще будет собирать в obj-i686-linux-gnu/obj-amd64-linux-gnu/...(всего 270 возможных вариантов). Всё не наигноришь.
Подождите, почему бы не использовать out-of-source билд и имя каталога привязывать например к бранчу, как-нибудь так?
То есть /build/<branch_name> — папка для сборки бранча?..
То есть /build/<branch_name> — папка для сборки бранча?..
Потому что при сборке пакета, если не писать полностью самому правила сборки (что есть неправильно), debhelper сам решает, в каком именно каталоге собирать. И поскольку структура файловой системы заранее неизвестна, сборка ВСЕГДА идёт не ниже корня пакета. Так что единственным способом является создавать для всего структуру типа:
Это не так удобно, и опять-таки, не позволит хранить каталог debian/ с инструкциями для сборки в SCM, только в ~/workspace/projectname/. Это не есть удобно.
~/workspace/ — каталог с проектами
~/workspace/projectname/ — «проект»
~/workspace/projectname/projectname-scm/ — настоящая папка с исходниками из гита
Это не так удобно, и опять-таки, не позволит хранить каталог debian/ с инструкциями для сборки в SCM, только в ~/workspace/projectname/. Это не есть удобно.
а можно подробнее про тихий ужас?
свн:
1. прописываем субрепу без ревизии. при каждом обновлении основной репы получаем обновления и субреп. внезапно и не вовремя.
2. прописываем субрепу с ревизией. чтобы обновить субрепы нужно узнать номер последней ревизии, изменить проперти основной репы и обновиться. много телодвижений.
гит:
основная репа и субрепы обновляются независимо. простыми движениями мы можем в любой момент:
1. обновить вообще всё
2. обновить только основную репу
3. обновить субрепы
4. обновить конкретные субрепы.
свн:
1. прописываем субрепу без ревизии. при каждом обновлении основной репы получаем обновления и субреп. внезапно и не вовремя.
2. прописываем субрепу с ревизией. чтобы обновить субрепы нужно узнать номер последней ревизии, изменить проперти основной репы и обновиться. много телодвижений.
гит:
основная репа и субрепы обновляются независимо. простыми движениями мы можем в любой момент:
1. обновить вообще всё
2. обновить только основную репу
3. обновить субрепы
4. обновить конкретные субрепы.
свн.1. Чтобы обновить без сабреп, достаточно использовать svn up --ignore-externals.
свн.2. Чтобы обновить экстернал, заходим в каталог с экстерналом, делаем svn up, заодно узнаём новую ревизию, много телодвижений.
гит.1. Я просто запишу это «простое» телодвижение:
Когда я работаю с корпоративным проектом, который использует пачку внутренних библиотек, я не хочу отслеживать состояние сторонних библиотек и самолично их апдейтить. Я подключаю транк, где должна лежать последняя рабочая версия, и всегда работаю с кодом со всеми исправлениями. Именно для этого подключается экстернал без указания ревизии. А в гите такой возможности технически нет, кроме как вышеупомянутыми макросовыми костылями. Точно так же придётся писать костыль, чтобы зачекаутить проект, проинициализировать сабмодули и потом их обновить с помощью вышеозначенного макроса. Одной командой это, разумеется, сделать нельзя.
Плюс интересное возникает при попытке сделать сабмодуль частью репозитория. Казалось бы, в чём проблема вмержить просто всю историю сабмодуля в родительскую, подправив пути. Но нет, при мерже репозиториев кутима мы попробовали ВСЕ способы, которые нашли в интернете, и в лучшем случае получали потерю половины истории.
свн.2. Чтобы обновить экстернал, заходим в каталог с экстерналом, делаем svn up, заодно узнаём новую ревизию, много телодвижений.
гит.1. Я просто запишу это «простое» телодвижение:
alias.up = "!git pull origin master;git submodule foreach --recursive 'git pull origin master'"Когда я работаю с корпоративным проектом, который использует пачку внутренних библиотек, я не хочу отслеживать состояние сторонних библиотек и самолично их апдейтить. Я подключаю транк, где должна лежать последняя рабочая версия, и всегда работаю с кодом со всеми исправлениями. Именно для этого подключается экстернал без указания ревизии. А в гите такой возможности технически нет, кроме как вышеупомянутыми макросовыми костылями. Точно так же придётся писать костыль, чтобы зачекаутить проект, проинициализировать сабмодули и потом их обновить с помощью вышеозначенного макроса. Одной командой это, разумеется, сделать нельзя.
Плюс интересное возникает при попытке сделать сабмодуль частью репозитория. Казалось бы, в чём проблема вмержить просто всю историю сабмодуля в родительскую, подправив пути. Но нет, при мерже репозиториев кутима мы попробовали ВСЕ способы, которые нашли в интернете, и в лучшем случае получали потерю половины истории.
свн1. а толку? любой чистый чекаут притянет последние версии субмодулей.
свн2. ага, потом копируем ревизию, идём в родительский каталог, читаем пропертю svn:externals, вставляем в нужное место скопированную ревизию, прописываем пропертю обратно. очень весело.
угу, должна, вот только там не только «последние исправления», но и «последние баги» и «последние изменения в апи» и вовсе не факт, что все эти последние изменения должны войти в ту версию продукта, которую ты сейчас разрабатываешь.
свн2. ага, потом копируем ревизию, идём в родительский каталог, читаем пропертю svn:externals, вставляем в нужное место скопированную ревизию, прописываем пропертю обратно. очень весело.
угу, должна, вот только там не только «последние исправления», но и «последние баги» и «последние изменения в апи» и вовсе не факт, что все эти последние изменения должны войти в ту версию продукта, которую ты сейчас разрабатываешь.
свн1. Свежий чекаут вообще всегда притягивает последнюю версию. И в свне, и в гите, и даже во всяких дарксах. Почему бы сабмодулям без указания ревизии надо вести себя по-другому?
свн2. Если это так сложно, воспользуйтесь гуёвыми утилитами. И, да, их в свн, точно так же, как и в гите, можно просто отредактировать в файлике. Только svn, в отличие от гита и его .gitmodules/.gitignore, складывает свою информацию в .svn/, а не срёт ей в корне репозитория.
Последние баги в транк попадать не должны. Если баги есть в стабильной версии в транке, это узнаётся всегда постфактум, конкретная используемая версия тут не причём. Ну а неожиданно менять в библиотеке апи, без сохранения обратной совместимости, в т.ч. бинарной… ну я даже не знаю, такое только в опенсорсе бывает, и то у школьников. Повторюсь, хотите жесткой привязки к конкретной ревизии — в свне эта возможность есть. А в гите обратной возможности нет.
свн2. Если это так сложно, воспользуйтесь гуёвыми утилитами. И, да, их в свн, точно так же, как и в гите, можно просто отредактировать в файлике. Только svn, в отличие от гита и его .gitmodules/.gitignore, складывает свою информацию в .svn/, а не срёт ей в корне репозитория.
Последние баги в транк попадать не должны. Если баги есть в стабильной версии в транке, это узнаётся всегда постфактум, конкретная используемая версия тут не причём. Ну а неожиданно менять в библиотеке апи, без сохранения обратной совместимости, в т.ч. бинарной… ну я даже не знаю, такое только в опенсорсе бывает, и то у школьников. Повторюсь, хотите жесткой привязки к конкретной ревизии — в свне эта возможность есть. А в гите обратной возможности нет.
свн1. потому что гит хранит не только ссылку на субрепу, но и сами исходники из неё. именно поэтому после коммита в субрепу надо сделать коммит в суперрепу, чтобы изменения отразились и на ней.
свн2. что за гуёвые утилиты? в гите мне не приходится ничего дополнительно редактировать после каждого апдейта субмодулей. и вопрос не в том какая система контроля версий лучше, а какой подход лучше. разумеется специальными скриптиками можно сделать работу с свн как в гите и с гитом как в свн-е. в данном случае подход свн-а вида «либо полная недетерминированность версии, либо кропотливое ручное изменение версий» никуда не годится по сравнению с гитовским «обновляемся по требованию»
ога, сферический транк в вакууме всегда стабилен х) а с чего ты взял, что неожиданно? вполне ожидаемо. библиотека развивается и поддерживать 100500 интерфейсов никому не нужно.
свн2. что за гуёвые утилиты? в гите мне не приходится ничего дополнительно редактировать после каждого апдейта субмодулей. и вопрос не в том какая система контроля версий лучше, а какой подход лучше. разумеется специальными скриптиками можно сделать работу с свн как в гите и с гитом как в свн-е. в данном случае подход свн-а вида «либо полная недетерминированность версии, либо кропотливое ручное изменение версий» никуда не годится по сравнению с гитовским «обновляемся по требованию»
ога, сферический транк в вакууме всегда стабилен х) а с чего ты взял, что неожиданно? вполне ожидаемо. библиотека развивается и поддерживать 100500 интерфейсов никому не нужно.
свн1. Гит не хранит исходники из сабрепы, даже каталог под неё (да, это тоже замечательная особенность гита — нельзя сохранить структуру каталогов). После чекаута надо делать git submodule update --init.
Впрочем, не понимаю, какое отношение это имеет к вопросу. git clone, bzr branch, darcs get, svn co — все они всегда выкачивают последнюю версию репозитория. Спрашивается, почему поведение сабмодуля, не привязанного к ревизии, должно при чекауте должно быть иным?
свн2. Тот же TortoiseSVN или просто любимые IDE. К счастью, в отличие от гита, который имеет исключительно набор бинарников (что вынуждает все веб-обёртки и аналогичные утилиты делать system(...) и парсить вывод), в свне есть библиотеки и можно работу с правкой любых свойств сделать сколь угодно удобной и кропотливо что-то править нигде не нужно. Если же говорить о подходе, то подход «обновляем по требованию» не лучше подхода «либо последняя версия, либо обновляем по требованию».
В школьной лаборатной или студии из полутора человек, возможно, библиотеки и «развиваются» подобным образом. В более-менее серьёзном софте — нет. Qt несколько лет поддерживала классы от Qt3, майкрософт десяток лет минимум поддерживал ansi-версии функций от winapi (если не поддерживает до сих пор). И так в общем-то делают все нормальные люди.
Впрочем, не понимаю, какое отношение это имеет к вопросу. git clone, bzr branch, darcs get, svn co — все они всегда выкачивают последнюю версию репозитория. Спрашивается, почему поведение сабмодуля, не привязанного к ревизии, должно при чекауте должно быть иным?
свн2. Тот же TortoiseSVN или просто любимые IDE. К счастью, в отличие от гита, который имеет исключительно набор бинарников (что вынуждает все веб-обёртки и аналогичные утилиты делать system(...) и парсить вывод), в свне есть библиотеки и можно работу с правкой любых свойств сделать сколь угодно удобной и кропотливо что-то править нигде не нужно. Если же говорить о подходе, то подход «обновляем по требованию» не лучше подхода «либо последняя версия, либо обновляем по требованию».
В школьной лаборатной или студии из полутора человек, возможно, библиотеки и «развиваются» подобным образом. В более-менее серьёзном софте — нет. Qt несколько лет поддерживала классы от Qt3, майкрософт десяток лет минимум поддерживал ansi-версии функций от winapi (если не поддерживает до сих пор). И так в общем-то делают все нормальные люди.
свн1. точно. я ж не использую сабмодули ^^' я просто создаю субрепозитории, но не прописываю их как субмодули. в этом случае в суперрепе хранятся строго определённые версии и субреп.
свн2. в данном случае гуёвые утилиты только добавляют сложности. эмм, про tortoisegit не слышал?
так делают те, у кого много ресурсов. обычный софт разрабатывается без поддержки мегатонн легаси кода. так что хватит пальцы гнуть.
свн2. в данном случае гуёвые утилиты только добавляют сложности. эмм, про tortoisegit не слышал?
так делают те, у кого много ресурсов. обычный софт разрабатывается без поддержки мегатонн легаси кода. так что хватит пальцы гнуть.
Мы тоже пользуемся SVN'ом. И хотя может быть и рады перейти на HG, но без нормальной поддержки Unicode'а на Windows пользоваться им невозможно. Не нравятся мне лично разные непонятно кем написанные fixutf8 плагины, которые того и гляди перестанут работать в следующей версии HG. А с GIT на Windows так еще хуже.
На данный момент SVN удобнее всего в плане совместимости для работы на Windows (VS, Eclipse, и еще туча IDE) + Mac OS (XCode).
На данный момент SVN удобнее всего в плане совместимости для работы на Windows (VS, Eclipse, и еще туча IDE) + Mac OS (XCode).
Им еще очень много кто пользуется, и будет пользоваться.
Да, в компаниях если все сидят в офисе в рамках одной сети. Subversion достаточно прост чтобы не преподносить сюрпризов при использовании большим количеством сотрудников с разной квалификацией. И достаточно вылизан за прошедшие годы чтобы на каждую сложную ситуацию был уже готовый кулинарный рецепт. Опять же, интеграция в IDE и Shell на данный момент у него лучшая — просто потому что он старше :).
А для «личного пользования» я тоже git и mercurial использую. Возможность коммитить в метро решает.
А для «личного пользования» я тоже git и mercurial использую. Возможность коммитить в метро решает.
Если в проекте работа с ветками довольно ограниченная, то svn вполне устраивает. Ну и такой фактор играет, что если как у нас более 10000 коммитов за 4 года, то переносить на другую платформу и терять историю не очень хочется.
Начиная с версии 1.6 svn вполне сносно работает с ветками :). Все претензии что «в git или hg бранчиться одно удовольствие, а в subversion первый же merge отправляет в ад» — это для старых версий где не было track merge info. А сейчас все нормально — лично я для большинства сценариев работы с ветками вообще не вижу разницы. Ну а собо сложные случаи — это на мой взгляд все-таки редкость.
Это, мягко говоря, неправда, потому что в свне ветка всё ещё — просто копия каталога со всеми вытекающими.
Особо сложные? В одной ветке достаточно внести изменения в файл, а в другой — его переименовать. При работе рефакторинга такое случается постоянно, к примеру. При этом Вы получите Tree Conflict на каждый такой файл и придется разгребать все руками. Что ж тут сложного…
А как Вы такое предлагаете разрулить автоматически?) Ну, мне просто интересно.
Да, у subversion отсутствует понятие «переименовать» — с точки зрения svn это будет «удалить» с последующим «добавить новый». Но в целом на практике такое случается на то чтобы часто, а конфликт разрешается в один клик.
Хм… как в Свн-е перенести локальные изменения из переименованного в новый файл?
В Свн, кстати, «добавить новый файл» и «скопировать существующий файл» — разные операции, т.ч. история копирования файла у него в общем-то есть.
В Свн, кстати, «добавить новый файл» и «скопировать существующий файл» — разные операции, т.ч. история копирования файла у него в общем-то есть.
После переименования в svn разрывается история файла.
Если пользоваться svn rename, то не разрывается.
Разве svn rename это не альяс для svn move?
Да, а еще к mv и ren.
Всё так. Но не все это понимают и делают. И уж удобным это точно не назовёшь.
Это вопрос тулсета и культуры, безусловно. Но та же IDEA при переименовании делает все верно, как и студия с правильными плагинами. Еще наверняка можно это коммит-хуком подпереть, который будет проверять, что очень похожий файл был удален и добавлен одновременно в одном ченж-листе. Понятно, что всей проблемы это не решит, но культура — штука сложная в любом случае. Тот же меркуриал тоже не любит, когда ему не подсказывают, что переименовали или скопировали. Только Гит умеет автоматом детектировать такие операции, но и он делает это не идеально, если содержимое файла при переименовании изменилось.
Подпирать не хочется ничем, ни IDE ни хуками. :)
Переименование и изменение нужно делать разными коммитами. Хотя, что это я вас учу? Судя по комментариям, вы и так прекрасно разбираетесь в вопросе.
Переименование и изменение нужно делать разными коммитами. Хотя, что это я вас учу? Судя по комментариям, вы и так прекрасно разбираетесь в вопросе.
… но современные GUI к ней замечательно это отслуживают и показывают историю целиком. Например, TortoiseSVN.
Создал тестовый репозиторий, добавил файл, закоммитил, переименовал файл, закоммитил, смотрю журнал — все есть. ЧЯДНТ? (svn 1.6)
Каким образом переименовал? svn rename или просто rename?
Проблема в том, что svn надо отдельно объяснять про rename. А что, если я переименую файл «руками»? Как мне ему объяснить про rename в момент коммита?
Проблема в том, что svn надо отдельно объяснять про rename. А что, если я переименую файл «руками»? Как мне ему объяснить про rename в момент коммита?
Кхм. Если вы в ЛЮБОЙ системе контроля версий переименуете файл «рукми» и системе контроля версий про этот печальный факт ничего не скажете — то он никак и не отразится.
Это неправда, Гиту о переименованиях сообщать не нужно — он отслеживает историю по содержимому, а не по имени файла, насколько мне известно.
Зато ему надо вручную указывать о том, что эти изменения надо коммитить :)
git commit -a
В смысле, какие изменения? То, что файл добавился?
Да. Иначе он это не закоммитит. Разница только в том, что git'у мы говорим о том что изменения надо коммитить, а subversion'у — о том, что изменения были. И там и там требуются некие дополнительные телодвижения.
Вы две разных операции в одну кучу смешали. Если я переименовал 100500 файлов, то в Гит-е мне закоммитить — одна команда, а в Свн-е — надо ломать голову, как объяснить системе контроля версий, что случилось. Это сильно разные вещи.
В гуях Меркуриала для этого спец. интерфейс есть с автопоиском переименований кстати.
В гуях Меркуриала для этого спец. интерфейс есть с автопоиском переименований кстати.
> А что, если я переименую файл «руками»?
> Как мне ему объяснить про rename в момент коммита?
Никак. Хотя, как мне кажется, и в svn можно добавить автоматизацию отслеживания переименований для файлов.
> Как мне ему объяснить про rename в момент коммита?
Никак. Хотя, как мне кажется, и в svn можно добавить автоматизацию отслеживания переименований для файлов.
Сделайте так:
— создайте папку, киньте в нее несколько файлов, закомитьте;
— удалите папку, создайте новую с тем же именем, накидайте в нее других файлов, попробуйте закомитить.
Не знаю как сейчас, но раньше svn не давала сделать коммит, т.к. считала папку новой, а такая папка на сервере уже есть.
— создайте папку, киньте в нее несколько файлов, закомитьте;
— удалите папку, создайте новую с тем же именем, накидайте в нее других файлов, попробуйте закомитить.
Не знаю как сейчас, но раньше svn не давала сделать коммит, т.к. считала папку новой, а такая папка на сервере уже есть.
ИМХО, логичное поведение, т.к. по сути директория и не была удалена из репозитория, поэтому:
1) создайте папку, киньте в нее несколько файлов, закомитьте;
2) удалите папку, закомитьте;
3) создайте новую с тем же именем, накидайте в нее других файлов, закомитьте;
Непонятно только зачем так делать? Почему не удалить все файлы и не добавить новые в существующую директорию?
1) создайте папку, киньте в нее несколько файлов, закомитьте;
2) удалите папку, закомитьте;
3) создайте новую с тем же именем, накидайте в нее других файлов, закомитьте;
Непонятно только зачем так делать? Почему не удалить все файлы и не добавить новые в существующую директорию?
Это НЕлогичное поведение. Осталась папка с таким же именем, изменилось только содержание.
Пример из жизни: решил поменять какую-то либу (уже в упор не помню какую) на новую. Снес из проекта старую папку с ней, вставил новую. Получил конфликт, на разгребание которого потратил время. Гит, к примеру, это съест и не поперхнется.
Второй пример: переделывали структуру папок с иконками для сайта. В итоге одна из папок после перетасовки оказалась на своем же месте. Точнее, на ее месте оказалась новая папка с таким же именем и содержанием. Но svn восприняла ее как новую и выкатила конфликт. И опять потеря времени на разруливание глупейшего конфликта.
Пример из жизни: решил поменять какую-то либу (уже в упор не помню какую) на новую. Снес из проекта старую папку с ней, вставил новую. Получил конфликт, на разгребание которого потратил время. Гит, к примеру, это съест и не поперхнется.
Второй пример: переделывали структуру папок с иконками для сайта. В итоге одна из папок после перетасовки оказалась на своем же месте. Точнее, на ее месте оказалась новая папка с таким же именем и содержанием. Но svn восприняла ее как новую и выкатила конфликт. И опять потеря времени на разруливание глупейшего конфликта.
Физическое удаление директории не означает её удаления из репозиториия — поэтому все действия над файлами/директориями в svn очень желательно производить с помощью соответствующих команд, тогда и проблем не будет.
Это просто одна из особенностей, к которой достаточно быстро привыкаешь.
Это просто одна из особенностей, к которой достаточно быстро привыкаешь.
Когда система контроля версий навязывает модель поведения — это первый звоночек, что пора ее менять. При работе с git я работаю с файлами так, как мне удобно, и это не вызывает никаких проблем.
С одной стороны, с другой — предостерегает от ошибок, т.к. приходится явно указывать что именно нужно. Удалив директории и создав новую с таким же названием — неизвестно что именно вы хотели сделать — удалить (разорвать историю) и создать новую или просто заменить существующие файлы. Именно поэтому это поведение мне кажется логичным.
Возможно, в 1.7 что-то поменялось в этом плане (не смотрел).
Возможно, в 1.7 что-то поменялось в этом плане (не смотрел).
В той папке была директория .svn где хранится информация о файлах репозитария
Сейчас она в корне рабочей копии. Может получше будет.
Вечером надо будет проверить.
Сейчас она в корне рабочей копии. Может получше будет.
Вечером надо будет проверить.
к слову сказать в mercurial есть автоматический импорт из SVN со всей историей.
Вы ошибаетесь, переход может быть очень болезненным. Например, если в репозитории хранятся большие файлы (~1ГБ), на 32ух-битных машинах меркуриал банально будет падать по out of memory. Если на репозитории есть разграничения прав, и люди работают с разными правами, то на меркуриале придется что-то придумывать. Если проект большой, и люди частенько выкладывают/забирают только необходимую часть, на меркуриале снова придется что-то изобретать.
Меркуриал и Гит — не замена Свн-а. Это другие системы, и подходы к работе с ними зачастую нужны так же иные. Это не говоря уже о том, что часть тулсета (билд-сервера, скрипты, коммит хуки, etc) может не поддерживать ничего кроме Свн-а или иметь проблемы с другими системами контроля версий.
Меркуриал и Гит — не замена Свн-а. Это другие системы, и подходы к работе с ними зачастую нужны так же иные. Это не говоря уже о том, что часть тулсета (билд-сервера, скрипты, коммит хуки, etc) может не поддерживать ничего кроме Свн-а или иметь проблемы с другими системами контроля версий.
Все так. Плюс у нас из редактора можно комитить сразу в свн, художники только так и работают…
А вы бы не могли привести примеры, что это могут быть за файлы монстры в репозитории? Нельзя ли их вынести за пределы репозитория?
Последний раз, что я видел — была пачка lib+pdb+dll файлов от сторонней библиотеки. Работа с одним ченж-листом съедала 4ГБ памяти в Меркуриале. Вынести их из репозитория нельзя, т.к. их надо версионировать вместе с кодом.
Это опасный путь. Во-первых, сам по себе сабрепо не решит проблемы нехватки памяти на 32ух-битных машинах и долгих апдейтов с диким потреблением памяти на остальных. Во-вторых, сабрепо требует еще пары очков в скиллах, чтобы им пользоваться, настраивать и т.п. Это все определенно не ляжет на чашу весов в пользу перехода на новую систему контроля версий.
Да, Вы правы, мне почему-то подумалось про работу с svn-сабрепо через hgsubversion. В Свн держать часть файлов вполне можно. Не считая усложнения настройки и доп. работы админам — думаю, это наиболее удобное решение.
Во всяком случае куда более удобное, чем сторонние тулзы для обновления зависимостей, особенно если нет необходимости «работать на другом конце земли и иметь всю историю изменений у себя», что требуется далеко не всем.
Во всяком случае куда более удобное, чем сторонние тулзы для обновления зависимостей, особенно если нет необходимости «работать на другом конце земли и иметь всю историю изменений у себя», что требуется далеко не всем.
Такие вещи надо выносить в artifact repository типа Nexus, как в Java делается. У нас пол-проекта С++ и все сторонние библиотеки так хранятся. Это уменьшило размер checkout-a ветки с порядка 5-7 гиг до порядка 100 мег (копии таких библиотек для 10+ платформ занимают дикое место). Соответственно ускорились все операции с веткой.
Это, кстати, тоже фактор, ограничивающий применение чего-либо, кроме SVN, в нашем случае — размер репозитория, из-за того, что в нем когда-то хранились бинарники, очень большой. Копировать его весь на каждую новую машину накладно, да и бессмысленно — мне вся эта история нужна, наверное, раз в день.
Это, кстати, тоже фактор, ограничивающий применение чего-либо, кроме SVN, в нашем случае — размер репозитория, из-за того, что в нем когда-то хранились бинарники, очень большой. Копировать его весь на каждую новую машину накладно, да и бессмысленно — мне вся эта история нужна, наверное, раз в день.
Это только один пример. В геймдев конторах, например, гигабайты может занимать контент без которого невозможно игру запустить. Бить его на части, поддерживать по разным репозиториям и т.п. — большой и кропотливый труд, которым зачастую просто некому заниматься.
насчет такого контента я могу согласиться — это тоже часто изменяемый контент, фактически такие-же исходники.
А библиотеки меняются редко — для них специальные репозитории подходят больше.
На самом деле, у нас все упиралось в размер и время checkout-a. Мы могли с тем-же успехом реорганизовать SVN так, чтобы в процессе сборки проекта вытаскивать только необходимые запчасти автоматически — это-бы не сильно отличалось от скачивания из репозитория.
А библиотеки меняются редко — для них специальные репозитории подходят больше.
На самом деле, у нас все упиралось в размер и время checkout-a. Мы могли с тем-же успехом реорганизовать SVN так, чтобы в процессе сборки проекта вытаскивать только необходимые запчасти автоматически — это-бы не сильно отличалось от скачивания из репозитория.
В крупных конторах поменять все пользовательские машины, билд-сервера, плюс операционки — вполне себе длительный и дорогостоящий процесс. Хотя вы безусловно правы, 32-бита становятся проблемой все меньше.
Я знаю множество проектов, у которых один только транк будет весить значительно больше гигабайта. Большинство современных игр для PC и консолей входят в это число.
Я знаю множество проектов, у которых один только транк будет весить значительно больше гигабайта. Большинство современных игр для PC и консолей входят в это число.
Просто в репозитории хранится графика. Но я все равно не понимаю, зачем засовывать туда сторонние библиотеки. Нельзя ли написать какой-нибудь скриптик, который будет по версии проекта скачивать с какой-нибудь шары соответствующую версию сторонней библиотеки и обновлять её корректно?
Конечно можно, какие вопросы.
Только посмотрите, что вышло из «безболезненного перехода»: надо всех научить пользоваться новой системой, поставить всем софт, рассказать про отличия, набить шишек, переделать скрипты, написать пачку новых, еще набить шишек, потратить Х часов каждого человека на вышеописанные процессы, натренировать админов, а потом, вот уже потом, сэкономить на времени апдейтов и мержей в течение хода проекта, и то не для всех членов команды, т.к. 2/3 и так не имели с этим проблем.
Встает закономерный вопрос: а есть ли у проекта время на все это, с учетом надвигающихся дедлайнов? Нередко, в силу рисков и затрат, дешевле и спокойнее остаться на том, что работает, пусть и не идеально. Что, разумеется, не отменяет возможности использовать Меркуриал/Гит на местах с Свн-ом в качестве центрального репозитория.
Только посмотрите, что вышло из «безболезненного перехода»: надо всех научить пользоваться новой системой, поставить всем софт, рассказать про отличия, набить шишек, переделать скрипты, написать пачку новых, еще набить шишек, потратить Х часов каждого человека на вышеописанные процессы, натренировать админов, а потом, вот уже потом, сэкономить на времени апдейтов и мержей в течение хода проекта, и то не для всех членов команды, т.к. 2/3 и так не имели с этим проблем.
Встает закономерный вопрос: а есть ли у проекта время на все это, с учетом надвигающихся дедлайнов? Нередко, в силу рисков и затрат, дешевле и спокойнее остаться на том, что работает, пусть и не идеально. Что, разумеется, не отменяет возможности использовать Меркуриал/Гит на местах с Свн-ом в качестве центрального репозитория.
Сторонние библиотеки — это удобно. Скачал и сразу работаешь. Если их надо отдельно ставить — это геморрой. Например за использовали вы библиотеку libXXX версии 1.4.6 локально она у вас есть, но вы не залили ее в репозиторий и тут у вас накрылся винт. Вы заново забираете свой проект их SVN, лезите на сайт библиотеки libXXX, а его нет! Лазите по инету, а там только последняя версия этой библиотеки есть libXXX 2.0.1, которая не совместима с вашим кодом. Все, проект переписывать? ( почти реальный случай )
А кто говорил, что библиотеки скачиваются с официального сайта руками? Библиотеки лежат тоже на локальном сервере.
Для сторонних библиотек нужно использовать менеджер зависимостей — ivy (http://ant.apache.org/ivy/), yfпример. В этом случае можно/нужно создать репозитарий в котором будут храниться нужные версии нужных библиотек, в проекта останется только перечислить их (и обновлять время от времени), вся остальная работа будет выполнена за вас.
Терять историю необязательно. Делаете
git svn clone --strlayout
--stdlayout если вы следовали tags/branches/trunk у себя в репозитории.
через полчаса (10000 дельт розрезолвить нужно) у вас гит копия репозитория с бранчами, тэгами и транком и с историей комитов. Потом git push в какой-то удаленный репозиторий и продолжаем дискотеку, работая уже с публичным репозиторием.
git svn clone --strlayout
--stdlayout если вы следовали tags/branches/trunk у себя в репозитории.
через полчаса (10000 дельт розрезолвить нужно) у вас гит копия репозитория с бранчами, тэгами и транком и с историей комитов. Потом git push в какой-то удаленный репозиторий и продолжаем дискотеку, работая уже с публичным репозиторием.
Я использую mercurial и svn для разных вещей, у каждого есть и плюсы и минусы.
Если в компании свн — стандарт, то никуда не денешься (
Я сделал свой репозиторий Hg в папке с проектом)
Лучше бы hgsubversion попробовали ;)
ну, я работаю с корпоративным svn из git-svn и ничего… правда, полную историю вытащить не удалось, иногда приходится лазить в svn смотреть annotate старых файлов… зато остальные плюшки git`а в наличии… ну и плюс для code collaborator`а пришлось скриптик сделать…
Я тоже пользуюсь SVN на работе. Репозиториям много лет, работа налажена и всем удобно. Дома пользуюсь git и mercurial. Но пока гораздо лучше владею SVN. Когда разберусь с гит или меркуриал, возможно задумаюсь о переходе, но пока не вижу в этом смысла. Ну т.е. тренироваться считаю уместным только дома, а не на рабочих проектах.
This directory includes an SQLite-backed database which contains all of the metadata
Сомнительное какое-то счастье… да еще и с копированием рабочей копии какие-то косяки обещают…
>> Позволяет сделать dump удаленного репозитория не имея к нему админского доступа.
Люди, объясните пожалуйста, зачем?
Люди, объясните пожалуйста, зачем?
Есть чужой репозиторий к которому доступ только на чтение. И нужно сделать клон — но не всего, а какой-то части. Раньше как — делаем svnsync всех этих терабайт в свой репозиторий, затем его уже dump и потом фильтруем что нам нужно. Теперь можно сразу сделать dump без промежуточных шагов и отфильтровать что нужно.
Опять же dump — это plain text. Так что можно сразу делать какие-то сложные автоматизированные операции / аналитику.
Опять же dump — это plain text. Так что можно сразу делать какие-то сложные автоматизированные операции / аналитику.
хорошая новость. ждем обновлений плагинов для эклипс
Ждем веток и нормальных мержей и можно возвращаться с меркуриала. Все-равно я им пользуюсь процентов на 10 только. Но ветки и бескровные мержи просто обязаны быть в любой vcs.
Если не секрет, какой merge будет считаться «нормальным»? Перпендикулярный чему? :)
Вы hg/git пользовались? Фича описана в любом мануале для переходящих с svn на hg/git.
Пользовался. Но хотелось бы услышать мнение живого человека. В мануалах оно много что пишут, но с ними обратной связи нема :).
Ну вот сделал брэнч от основного. Потом в обоих брэнчах что-то меняешь, коммитишь. А потом в какой-то момент мержишь. И оно-таки мержит, причем в обе стороны, без малейшего писка. После svn — удивительно. Там приходилось разруливать руками, тулзами типа meld.
Если нет конфликтов содержимого (в обоих ветках поменяли одну и ту же строчку в файле) и конфликтов структуры (в одной ветке файл переименовали в одно имя, в другой ветке — в другое) то merge в git и subverson выглядит абсолютно одинакого. Не первый год уже пользуюсь и тем, и тем.
Единственная известная мне разница — subversion не делает автоматический merge если в одной ветке файл был переименован/перимещен, а в другой изменен. Я пока не разобрался почему так (выше написали, что информацию об перемещении subversion все таки хранит) — но это не то чтобы очень часто случается.
Единственная известная мне разница — subversion не делает автоматический merge если в одной ветке файл был переименован/перимещен, а в другой изменен. Я пока не разобрался почему так (выше написали, что информацию об перемещении subversion все таки хранит) — но это не то чтобы очень часто случается.
В svn линейная нумерация чейнджсетов и нету брэнчей, поэтому сложные мержи тупо не понятно, откуда куда делать. В hg они просто нарисованы графом.
Я не то что б сильно против svn, благо работал с ним лет 8, но hg мне показался в работе гораздо удобнее.
Я не то что б сильно против svn, благо работал с ним лет 8, но hg мне показался в работе гораздо удобнее.
Посмотрите в Release Notes раздел Merge-Tracking Enhancements, там довольно много изменений, даже странно, что не они не попали в этот топик.
Осталось подождать, пока JetBrains в свои клёвые IDE прикрутит поддержку 1.7. А то сообщения типа «Project is likely to be of unsupported Subversion format» немного огорчают.
А может кто-нибудь рассказать в 2х словах за счет чего достигается «бескровность» мерджей в гите/меркуриале? Сам работал только с свн'ом. Вот например такая ситуация: 2 человека меняли одну и ту же функцию в коде, причем один из них чинил уже готовую логику (ну и еще в порыве рефакторинга попутно переименовав какую-нибудь переменную), а второй добавил новую функциональность (ну хотя бы дополнительный необязательный параметр, и небольшое условие с ним внутри) — при мердже будет конфликт, к гадалке не ходи; разбирать придется руками. Неужели гит сможет в такой ситуации сам все разрулить? Как? Если да, то я инициирую на работе гит-революцию =) Ну а если нет, то все более простые случаи конфликтов обычно не причиняют проблем и нечего дергаться лишний раз.
Описанная ситуация действительно не будет отличаться для svn/hg/git. Обычно когда говорят про проблемы с ветками в svn имеют в виду, что после merge двух веток приходится ветку удалять и создавать новую, либо записать на бумажке номер ревизии до следующего merge. Это починили пару лет назад в версии 1.5, ЕМНИП. Вторая проблема — невозможность создавать локальные ветки.
Неужели гит сможет в такой ситуации сам все разрулить?
Нет конечно. Тут несколько факторов:
1. Subversion до версии 1.6 не делал mergeinfo. Соответственно, тривиальная задача регулярного обновления рабочей ветки по результатам изменения trunk вынуждала каждый раз вручную указывать диапазон ревизий trunk, для которых мы хотим делать merge. Начиная с версии 1.6 subversion хранит mergeinfo (какие ревизии куда делали merge) и merge стал работать так же как в git и mercurial.
2. Subversion не понимает move и rename — для svn это значит «удалить и создать новый файл». Соответственно, если один разработчик файл поменяет а второй переименует — для subversion это будет конфликт файловой структуры, который надо разрешать вручную. Git и Mercurial это… хмм… относительно поддерживают :).
За меркуриал не скажу, а в git это не конфликт потому, что в git имя файла и его содержимое разнесены.
1. mergeinfo появилась в SVN 1.5 а не 1.6
svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html
2. svn move — эквивалент svn copy + svn delete. Т.е. нет создания нового файла, он помнит, что это копия старого.
svnbook.red-bean.com/en/1.2/svn.ref.svn.c.move.html
Если один программист поменял файл, а другой переместил/переименовал (т.е. удалил после копирования) — конечно это должно быть конфликтом, ибо первый программист рассчитывал на то, что файл называется/находится по-старому.
Так что тут, имхо, SVN прав.
svnbook.red-bean.com/en/1.5/svn.ref.svn.c.mergeinfo.html
2. svn move — эквивалент svn copy + svn delete. Т.е. нет создания нового файла, он помнит, что это копия старого.
svnbook.red-bean.com/en/1.2/svn.ref.svn.c.move.html
Если один программист поменял файл, а другой переместил/переименовал (т.е. удалил после копирования) — конечно это должно быть конфликтом, ибо первый программист рассчитывал на то, что файл называется/находится по-старому.
Так что тут, имхо, SVN прав.
Я немного отстал от жизни, поэтому хотелось бы задать один вопрос активным пользователям последних версий Subversion: эта VCS все еще делает полное копирование все файлов в отдельный каталог, если я хочу создать новую ветку? Если нет, то есть ли сейчас смысл в структуре «branches/tags/trunk»?
Спасибо
Спасибо
С точки зрения репозитория сохраняется только diff. Сделанная копия сразу после изготовления не занимает места. С точки зрения файловой системы переключение каталога с одной ветки на другу удаляет, добавляет и меняет только те файлы, которые в них различаются.
> Только одна папка .svn в корне
означает ли это, что теперь нет возможности для checkout'a только части дерева?
означает ли это, что теперь нет возможности для checkout'a только части дерева?
Да! И я рад, что это извращение запретили :). Потому что дерево папок, в котором разные подпапки указыают на разные ветки и ревизии — это ад.
Есть, эта фича затрагивает только клиентскую часть. У части дерева будет свой каталог .svn, но только один. Если я правильно понял release notes.
Да. Поскольку подпапки .svn в них нет, то и за рабочую копию или ее часть это не считается. Вверх по дереву папок оно не ищет =(
> Начиная с версии 1.7 subversion не будет создавать в каждой папке свою подпапку ".svn"
Это ж писать кипятком во всех направлениях
Это ж писать кипятком во всех направлениях
Пользовался 3 года SVN, потом наша контора пересела на Hg — работаем на нём уже почти два года. Назад на SVN не хочется, да и в личных целях стал всегда использовать меркуриал.
Те кто говорят, что им и SVN-a хватает, — либо не пробовали вообще либо толком не разобрались с Hg/Git.
Ну а новость хорошая, радует что SVN живет и развивается. Даже слабая конкуренция стумулирует развитие отрасли в целом.
Те кто говорят, что им и SVN-a хватает, — либо не пробовали вообще либо толком не разобрались с Hg/Git.
Ну а новость хорошая, радует что SVN живет и развивается. Даже слабая конкуренция стумулирует развитие отрасли в целом.
Глупо сравнивать распределённые хранилища и централизованные. Везде есть свои плюсы и минусы.
ну вот я 2 года проработал на Tortoise SVN. Все нравилось, все удобно, не нашел ни одного момента, которого мне бы не хватало. Сейчас по приказу начальства пересаживаемся корпоративно на GIT. Без обсуждений.
Ну поставил я себе Git for windows, ну увидел, что софт кривой:
1. вот зачем менять иконки cmd на таск баре??? ну вроде ж мелочь? Но все же? Нафига мне эта надпись GIT на каждой иконке каждой командной строки? При чем там гит к cmd, route print? или тому подобному?
2. решили работать по нестандартному порту. Так эта гадость в своих же GUI интерфейсах не понимает номер порта после адреса. И через пробел пробовали, и через двоеточие, и все что в голову приходило. Даже в ковычки брали. Ну никак не хочет.
3. Поставил Tortoise GIT. С ним попроще. Но Merge tool работает безобразно в сравнении с SVN (который мержил без вопросов гораздо более сложные изменения и даже не чихал).
Понравился «карман». И как-то ВСЕ!
И смысл на такое садиться? :(
Ну поставил я себе Git for windows, ну увидел, что софт кривой:
1. вот зачем менять иконки cmd на таск баре??? ну вроде ж мелочь? Но все же? Нафига мне эта надпись GIT на каждой иконке каждой командной строки? При чем там гит к cmd, route print? или тому подобному?
2. решили работать по нестандартному порту. Так эта гадость в своих же GUI интерфейсах не понимает номер порта после адреса. И через пробел пробовали, и через двоеточие, и все что в голову приходило. Даже в ковычки брали. Ну никак не хочет.
3. Поставил Tortoise GIT. С ним попроще. Но Merge tool работает безобразно в сравнении с SVN (который мержил без вопросов гораздо более сложные изменения и даже не чихал).
Понравился «карман». И как-то ВСЕ!
И смысл на такое садиться? :(
никогда не использовал Git, но все равно попытаюсь ответить на вопрос, в свете личного опыта использования Hg
1. Дело личного вкуса каждого, кому какие иконки нравятся. На суть работы это сильно не влияет, да и вообще я сторонник того что Hg следует использовать через Tortoise 2.x, только GUI позволит полностью насладиться всей мощью этой CVS
2. Особенности настройки — что-то вы не так готовите, тот же Hg центральный репозиторий настраивается за полчаса максимум, на любой порт. Думаю что с Git дела не намного хуже.
3. Tortoise Hg позволяет настроить его дифф и мерж на любой merge tool, который поддерживает передачу параметров через командную строку, я araxis подключал без проблем.
Кроме того Hg содержит кучу встроенных екстеншенов, которые очень сильно упрощают работу с ним. Просто ради интереса проидитесь по списку и почитайте какой что умеет делать.
1. Дело личного вкуса каждого, кому какие иконки нравятся. На суть работы это сильно не влияет, да и вообще я сторонник того что Hg следует использовать через Tortoise 2.x, только GUI позволит полностью насладиться всей мощью этой CVS
2. Особенности настройки — что-то вы не так готовите, тот же Hg центральный репозиторий настраивается за полчаса максимум, на любой порт. Думаю что с Git дела не намного хуже.
3. Tortoise Hg позволяет настроить его дифф и мерж на любой merge tool, который поддерживает передачу параметров через командную строку, я araxis подключал без проблем.
Кроме того Hg содержит кучу встроенных екстеншенов, которые очень сильно упрощают работу с ним. Просто ради интереса проидитесь по списку и почитайте какой что умеет делать.
Раз зашел разговор про Git выложу еще и ссылку на великолепный проект — Gerrit. Code Review + Access control для git репозиториев code.google.com/p/gerrit/
Вот работающий пример review.cyanogenmod.com/#q,status:open,n,z
Вот работающий пример review.cyanogenmod.com/#q,status:open,n,z
Как бы его на Ubuntu обновить?
не помогает
из исходников тоже не получается:
apt-get update && apt-get upgradeне помогает
# svn --version
svn, version 1.6.12 (r955767)
compiled Jun 5 2011, 15:03:40из исходников тоже не получается:
configure: error: no suitable APRUTIL foundwget apache.vc.ukrtel.net/subversion/subversion-1.7.0.tar.gz
tar xvf subversion-1.7.0.tar.gz
cd subversion-1.7.0
apt-get remove subversion
apt-get install libapr1 libapr1-dev libaprutil1-dev autoconf libtool
./configure
make installвсё равно не получается, пишет
test -d /usr/local/include/subversion-1 || \
/usr/bin/install -c -d /usr/local/include/subversion-1
(subversion/svnversion/svnversion . 2> /dev/null || \
svnversion . 2> /dev/null || \
echo "unknown"; \
) > /usr/local/include/subversion-1/svn-revision.txtЗарегистрируйтесь на Хабре, чтобы оставить комментарий
Состоялся релиз subversion 1.7