LINUX.ORG.RU

svn vs git (опять и снова)

 , ,


1

2

На новом проекте (по определенным причинам) приходится работать под svn (до этого всю свою сознательную жизнь работал с git). О svn знал, но что это такое... своеобразие понял только сейчас. На каждый чих нужен коннект к центральному репозиторию (что впринципе логично для не DCVS), но после git смотрится очень странно. + я часто люблю попилить проекты дома. С git всё просто, но с svn (когда доступа к внутреннему серваку с svn со вне нету) это стало нереально. Вообщем, я так и не понял прелести svn (да, больших блобов в проекте нет, нужды редактировать *только* отдельный файл нету, без проблем выкачивается все дерево, благо 100мб сейчас не проблема).

Заодно, после всего этого сумбура, прошу совета: как лучше совместить svn и git? слыхал про git svn, но каких-то нормально работающих примеров не нашёл.

Ответ на: комментарий от GreenBag

Какая «такая» сила воли? Наоборот, гигантская силища воли нужна, чтобы каждый день вставать и тащиться на такую работу. Я бы точно не осилил. А уйти - много силы не надо, достаточно заявление в один лист настрочить.

anonymous
()
Ответ на: комментарий от anonymous

Я выполняю свою работу и самообучаюсь в это время. Проще говоря, набиваю руку. Ты прав, конечно, но есть много разных «НО». Допустим, даже тут работает несколько «нормальных» людей, у которых есть чему поучиться. А контора что со мной, что без меня продержится, ибо даже говнокод часто работает вполне себе, только вот сопровождать его противно.

panter_dsd ★★★★
()
Ответ на: комментарий от panter_dsd

надо это с лидером задружится и ему периодически за пивом предлагать на гит перейти...

Thero ★★★★★
()
Ответ на: комментарий от anonymous

Ты крут, анонимус, раз знал обо всём этом в середине 80х. Но слишком категоричен. Те, которые под досятину говногодили, никуда не делись. Они жили в своих замкнутых мирках с узким кругом общения, им практически неоткуда было узнать что-то новое. Одни в своё время смогли выйти из своих мирков в большой мир, другим это далось труднее, и они так и остались где-то посередине. Может они и ламерьё по меркам отдельных индивидуумов, но насчёт самоуважения и их уважения со стороны других людей у них было всё в порядке. И эти люди никуда не делись, они и сейчас среди нас.

Sorcerer ★★★★★
()

когда доступа к внутреннему серваку с svn со вне нету

vpn?

hatefu1_dead
()
Ответ на: комментарий от Sorcerer

Люди-то они может и люди, и может даже и хорошие. Но они ни хрена не разработчики, и не имели ни малейших шансов стать таковыми.

anonymous
()
Ответ на: комментарий от anonymous

А прелести у svn есть - централизация, hook-и, правила всякие.

Что в git мешает сделать единственный продакшн-сервак, куда будут push-ить свои изменения разработчики? Что в git не так с хуками? Каких правил тебе не хватает?

post-factum ★★★★★
()
Последнее исправление: post-factum (всего исправлений: 1)
Ответ на: комментарий от Minoru

Злостное 4.2. git развертывается в любой из директорий за 3 секунды: $ git init

я сделаю это за 2 секунды! ))

quest ★★★★
()
Ответ на: комментарий от GreenBag

Не надо любой. Конкретно пишите в терминале «git gui» и будет вам счастье.

trex6 ★★★★★
()
Ответ на: комментарий от Debasher

Я слышал, что cvn - тормозное глюченное говно, могу ошибаться. Сам юзал гит, не жалуюсь.

Реквестирую в квотезы!

KennyMinigun ★★★★★
()
Ответ на: комментарий от anonymous

Еще и сам отупеешь.

Это да, в таких конторах зачастую бытие определяет сознание...

quest ★★★★
()
Ответ на: комментарий от post-factum

time git init

Вообще я говорил о минимальной настройке без gitosis - завести на удаленой машине акканунт, создать там репозитарий, сгенерировать ключи, пробросить туда открытый ключ, сделать git clone - думаю около минуты...

quest ★★★★
()
Ответ на: комментарий от aol

Пересаживались на работе с svn на git, дерево импортировали, проблемы были, да. Он иногда не все коммиты выгребал.

invy ★★★★★
()
Ответ на: комментарий от Debasher

Тогда это в стиле «рабинович напел». Если репозиторий занимает несколько гигабайт, содержит миллионы файлов и особенно блобы, то svn здесь равных даже близко нет.

Reset ★★★★★
()
Ответ на: комментарий от panter_dsd

Вот почитаешь тебя и на работу устраиваться побоишься.

HerrWeigel ★★★★
()
Ответ на: комментарий от Reset

Ну я и говорю, что могу ошибаться. Не специалист в этом деле

Debasher ★★★★★
()
Ответ на: комментарий от panter_dsd

exe'шники могут быть собраны/слинкованы с разными версиями sdk, поэтому просто вытягивание сорцов по тегу не даст в точности ту же версию. Их можно понять. Сделали тупое примитивное решение в лоб и не стали заморачиваться.

Reset ★★★★★
()
Ответ на: комментарий от Sorcerer

Не обижайте svn. Это хорошая система контроля версий для своего времени. Когда она создавалась, DVCS ещё не были популярны, а git не было вовсе. Зато был cvs, вот по сравнению с ним svn - это мегакрутой прогресс.

Ну, знаете, я тоже так думал. Но вот вышла версия 1.7 и FreeBSD перешли на svn, и я уже не так уверен. Начну с того что с централизованной vcs, у которой сервер на другой стороне планеты работать в принципе невозможно - log, update висят по несколько секунд. Ладно. svn ухитряется при этом тормозить куда заметнее cvs. Тоже ладно. Но есть очевидное решение - поднять зеркало и спокойно с ним работать. Так я делал с cvs и горя не знал. У лапочки git, понятно - это из коробки. Через svnsync зеркало репы на svn тоже делается без проблем. Но! Это угребище тупо не умеет коммитить и обновляться из разных реп! То, что везде делается одни ключом (cvs -p, git push <просто_куда>), в svn не делается никак! Полез в код, сидел двое суток, плюнул. Не переписывая весь svn, с его кучей библиотек и адским дублированием кода опцию, которая тупо подменяет репозиторий туда не запихнуть! Другие варианты? Их есть - svn relocate. Работает замечательно, кажется даже в сеть не лезет, только вот незадача - он походу обходит весь чекаут, а чекаут FreeBSD'шных портов весьма, знаете ли, немаленький. А самое смешное - в версии 1.6 в каждой поддиректории чекаута была своя .svn, и можно было за'relocate'ить её. А сейчас - хрен, слижем с git одну директорию и впендюрим туда sqlite.

В общем так и не придумал - пока мучаюсь. Видимо придётся над репозиторием поднимать сервер и что-то делать через подмену hosts или gethostbyname через LD_PRELOAD, чтобы таки подсунуть ему другую репу.

Так что нужно быть честным - централизованные VCS - пройденный этап и должны вымереть. А svn - и подавно, как эталон кривейшей реализации централизованной VCS.

slovazap ★★★★★
()
Ответ на: комментарий от slovazap

В общем так и не придумал - пока мучаюсь.

А может ну его нахер, а? Зачем участвовать в проектах, которые не уважают своих пользователей.

mashina ★★★★★
()
Ответ на: комментарий от slovazap

В общем так и не придумал - пока мучаюсь.

Вам важно использовать непременно клиент svn для коммитов? Можно ведь git'ом или mercurial'ом клонировать репозиторий svn на зеркале, а дальше работать с зеркалом и горя не знать.

А самое смешное - в версии 1.6 в каждой поддиректории чекаута была своя .svn, и можно было за'relocate'ить её. А сейчас - хрен, слижем с git одну директорию и впендюрим туда sqlite.

А зачем обходить весь чекаут для relocate, если директория .svn теперь одна, как Вы говорите? Странно.

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

Я этого и не отрицал.

А svn - и подавно, как эталон кривейшей реализации централизованной VCS.

Так уж и кривейшей. То, что svn со скрипом вписывается в ваш workflow с элементами DVCS - не удивительно, потому что это централизованная VCS. Зато если нет задачи децентрализации, а проект не такой огромный, как порты freebsd, то svn справляется достаточно хорошо (для централизованной VCS: с DVCS не сравниваем).

Вообще freebsd, кажется, давно ведь перешли на svn. Или нет? Переходить на svn сейчас, в эпоху DVCS, - как-то неразумно. Когда я использовал freebsd (несколько лет назад), svn уже можно было использовать, по-моему, но, возможно, не для портов.

Sorcerer ★★★★★
()
Ответ на: комментарий от panter_dsd

Все это команда разработчиков. Им удобно это хранить в svn, а не на файловом сервере. Пусть хранят в svn это их право, не вижу никаких проблем. Если тебе это не нравится, то увольняйся и ищи другую работу.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Файлы хранятся сейчас и там, и там, что есть избыточно. А смысл твоей фразы по поводу смены работы я не понял - я же не на тебя наезжаю, не тебя учу, как жить. Я просто выразил свое мнение, что хранение exe в svn бессмыслено.

panter_dsd ★★★★
()
Ответ на: комментарий от panter_dsd

Я просто выразил свое мнение, что хранение exe в svn бессмыслено.

Это только твое мнение. Кто-то с ним может быть не согласен. Мне тоже не нравится хранение бинарей в svn, но я прекрасно понимаю зачем так делают.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Shallow clone для такого говна никто не отменял. Да и на кой такие репозитории-то нужны, без модулей-то? Если разработчики и админы идиоты, то их увольнять надо, а не оправдывать употребление говняшки svn кадровыми проблемами.

anonymous
()
Ответ на: комментарий от anonymous

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

Reset ★★★★★
()
Ответ на: комментарий от Reset

В svn модульность - такой же костыль. Решения с git и hg ничуть не хуже (и не лучше). А вообще, за огромные репозитории с бинарниками надо руки отрубать.

anonymous
()
Ответ на: комментарий от anonymous

В svn модульность - такой же костыль.

Почему ? Там модульность на уровне директорий из коробки

Решения с git и hg ничуть не хуже

Хуже, так как из коробки их нет вообще.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Зачем «из коробки»? Есть submodules, их более чем достаточно.

anonymous
()
Ответ на: комментарий от Reset

примитивное полурабочее говно

молодец. Уважаю. Умеешь тявкать не(только) под аноном.

Кроме тявканья аргументы ещё будут?

drBatty ★★
()
Ответ на: комментарий от drBatty

молодец. Уважаю. Умеешь тявкать не(только) под аноном.

Я не тявкал и не оскорблял участников дискуссии.

Кроме тявканья аргументы ещё будут?

Да. Оно просто не работает. Надо либо всегда работать с полным деревом сабрепозиториев, делая коммиты из корня, либо версии будут разъезжаться.

Reset ★★★★★
()
Ответ на: комментарий от Reset

Да. Оно просто не работает. Надо либо всегда работать с полным деревом сабрепозиториев, делая коммиты из корня, либо версии будут разъезжаться.

почитал дискус. Что мне сказать - твоя идея хранить exe(obj) внутри репозиторя - кривая by design. Очевидно, и все решения будут кривыми. Хоть hg subrepos, хоть svn.

Если калькулятор X при делении на ноль перезагружается, а калькулятор Y при той же операции пишет infinity, то неправильно работают оба. Потому-что делить на ноль нельзя. Правильный калькулятор _обязан_ отказаться выполнять данную операцию.

drBatty ★★
()
Ответ на: комментарий от drBatty

Что мне сказать - твоя идея хранить

Это не моя идея. Еще раз повторю, что я эту идею не поддерживаю, но понимаю зачем так делают.

Хоть hg subrepos, хоть svn.

В subrepos это вообще не работает и не только потому что subrepos кривой, а еще потому что hg (и гит) в общем случае не умеют работать с блобами (largefile по понятным причинам не учитываем)

Reset ★★★★★
()
Ответ на: комментарий от Reset

Это не моя идея. Еще раз повторю, что я эту идею не поддерживаю, но понимаю зачем так делают.

а я вот не понимаю.

В subrepos это вообще не работает и не только потому что subrepos кривой, а еще потому что hg (и гит) в общем случае не умеют работать с блобами (largefile по понятным причинам не учитываем)

а как работать с блобами? причём тут вообще VCS? hg прекрасно «работает» с любыми блобами, достаточно занести их в .hgignore.

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.