Здравствуйте, Sergey J. A., Вы писали:
SJA>И git запомнит, что вот эти файлы из этого комита замержены а остальное нет? При последующем мерже этого-же комита что произойдёт?
Git при мердже всегда оперирует коммитами, а не отдельными файлами. Либо мердж между коммитами успешный, либо нет, но операция всегда атомарная.
Если я правильно понял — у нас есть, например, 5 файлов. Нам нужно закомитить сейчас 2 из них. Создаём коммит с 2мя файлами.
Теперь нам нужно отправить этот комит в основную ветку. Так как у нас есть изменённые ещё 3 файла — временно отправляем эти 3 файла
в стэш (временное хранилище). После этого мержим наш 2х файловый комит в основую ветку. Если позникают неоднозначности — фиксим и заканчиваем мердж.
Достаём из стэша оставшихся 3 файла и продолжаем над ними работу.
Если же мы про rebase и возникающие конфликты — то, по умолчанию, их придётся каждый раз фиксить. Или же можно включить запоминатель разрешения
конфликтов http://git-scm.com/blog/2010/03/08/rerere.html и при повторном возникновении того же конфликта git сам всё сделает.
Здравствуйте, Sergey J. A., Вы писали:
D>>И что это показывает? Что дурная голова рукам покоя не дает?
SJA>Именно это и показывает. Не svn или git, а дурная голова. SJA>Заявленное "делай что хочешь" несколько не соответствует действительности.
Причём тут голова? Я о принципе наименьшего удивления. Я имею в виду, что если ты делаешь какие-то операции, которые не предназначены что-то удалять (скажем svn up), то в хорошей VCS не должна возникать ситуация, когда нельзя операции откатить, и приходится "присохраняться" тупым копированием в хз какие бекапы. А если ты явно набираешь три довольно хиртые команды чтобы всё уничтожить, то собственно это и ожидаешь.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Sergey J. A., Вы писали:
SJA> .>Это простая операция, не так заметно. А update проекта 1000 каталогов? А переключение бранча? Создание бранча? Поиск в истории? Разница порой будет уже не пять раз, а пять тысяч.
SJA> Итак наш транк. SJA> Far говорит: Поиск закончен. Найдено файлов: 32996, папок: 3497 SJA> (само собой без .svn)
SJA> Чистил кэш утилитой RAMMap. Не уверен, насколько это адекватно, но другого способа я не знаю. SJA> (RAMMap -> Menu -> Empty -> Empty Standby List)
Для более-менее честного тестирования импортируй svn в git ( git svn clone <svnurl> ) и гоняй тесты.
На моем достаточно маленьком репо (7200 ревизий svn, 2486 файлов, папки не считал):
log:
time svn log --limit 100 > /dev/null
svn log --limit 100 > /dev/null 0.02s user 0.01s system 2% cpu 1.274 total
time git log -n 100 > /dev/null
git log -n 100 > /dev/null 0.00s user 0.01s system 46% cpu 0.021 total
blame для первого попавшевося файла:
time svn blame Class.java >/dev/null
svn blame > /dev/null 0.04s user 0.04s system 4% cpu 1.748 total
time git blame Class.java > /dev/null
git blame > /dev/null 0.05s user 0.01s system 78% cpu 0.069 total
status:
time svn status > /dev/null
svn status > /dev/null 0.02s user 0.06s system 80% cpu 0.100 total
time git status > /dev/null
git status > /dev/null 0.01s user 0.01s system 69% cpu 0.024 total
В git делай что душе угодно, в каком хочешь порядке.
SJA> Моей душе было угодно выполнить эти хитрые команды. Я уж и незнаю, что больше сказать.
Буквоедство. Я же тебе порекомендовал: "rm -rf *", и не стоило время тратить на гугл в поисках этих трёх команд.
Здравствуйте, Sergey J. A., Вы писали:
SJA> В итоге всё пучком до сих пор. Мержит приемлимо, скорость достаточная, сон спокойный. SJA> Пару новых проектов я завёл в git, все open source проекты тоже git. Полёт нормальный, нравится, но страстного желания переводить всё на гит пока не возникает.
Хорошо. Сойдёмся на том, что для некоторых корявых легаси систем в некоторых случаях svn или zip в качестве vcs могут быть лучше.
SJA> Начинать писать на коболе — да, не стоит. Если надо поправить пару параметров — лучше не бросаться всё переписывать. SJA> У меня нет никакого желания улучшать структуру проектов и избавляться от бинарников в VSS-е что бы потом, через лет так 5 (полагаю столько займёт переход на svn, если на это не будет выделятся ресурсы) перейти на git.
Есть такая вещь как technical dept, если проект не сдохнет, то платить его таки придётся.
SJA> С++/.NET. nexus/artifactory/archiva/nuget пробовал — немного не то. Хотя углубленно не копал.
А что не срослось?
SJA> Почему не пушишь в 10 раз чаше? Неужели пуш медленный?
После того, как мы завели gerrit, пушить тоже стал чаще на порядок — накой самому гонять тесты и т.п., пусть CI-сервер трудится, он железный.
SJA> Я то предпочитаю хорошо оформленные комиты, но если кого-то останавливает только скорость коммита/пуша... Мда.
Я могу сделать коммит, заняться чем-то другим, закоммитить, потом обнаружить, что какой-то тест валится, чуток исправить код, поправить сообщение, дописать ссылки на пофикшенные баги когда полезу в багтрекер. В общем оформление коммита это превращается из события, требующего серьёзного и ответственного отношения (как будто правишь софт для ядерного реактора), а простой процесс с кучей черновиков (как будто правишь домашнюю страничку для васи пупкина).
SJA> Я сделаю замеры. Но вот, как с технической точки рения ты полагаешь, что update, branch, switch будет медленнее?
Практически все svn операции требуют сетевое соединение. У гит их только две — push и fetch (pull). Скажем, создание бранча в гите это просто создание файла в каталоге ".git/refs/heads/" размером 40 байт, пара миллисекунд, на порядок меньше типичного пинга в сети.
update (pull) если без локальных изменений — просто fetch (который, например, Atlassian SourceTree делает в бэкграунде), и fast-forward merge — просто распаковка изменённых файлов в working copy.
SJA> Нет, у нас другой процесс. Но я имел в виду просмотр *своих* изменений перед комитом.
Удобнее изменения делать и просматривать по частям: первый коммит — поправить форматирование кода, второй коммит — рефакторинг, третий коммит — новые изменения. Пушим пачкой.
Здравствуйте, ., Вы писали:
.>Хорошо. Сойдёмся на том, что для некоторых корявых легаси систем в некоторых случаях svn или zip в качестве vcs могут быть лучше.
Если разницы между zip и svn не видно, то и смысла что-то обсуждать не вижу.
Здравствуйте, Clerk, Вы писали:
C>Если я правильно понял — у нас есть, например, 5 файлов. Нам нужно закомитить сейчас 2 из них. Создаём коммит с 2мя файлами. C>Теперь нам нужно отправить этот комит в основную ветку. Так как у нас есть изменённые ещё 3 файла — временно отправляем эти 3 файла C>в стэш (временное хранилище). После этого мержим наш 2х файловый комит в основую ветку. Если позникают неоднозначности — фиксим и заканчиваем мердж. C>Достаём из стэша оставшихся 3 файла и продолжаем над ними работу.
это уже звучит как минимум не "просто"
... а теперь еше усложним — представим что пока я правил эти 2 файла на остальные другие разрабы
уже повесили 100500 коммитов
я на самом деле не спец по гиту, просто бесит последняя программерская тенденция использовать то что модно а не что реально надо
Здравствуйте, The Passenger, Вы писали:
TP>это уже звучит как минимум не "просто"
TP>... а теперь еше усложним — представим что пока я правил эти 2 файла на остальные другие разрабы TP>уже повесили 100500 коммитов
Да хоть сто тысяч миллионов. Git сам всё замержит.
TP>я на самом деле не спец по гиту, просто бесит последняя программерская тенденция использовать то что модно а не что реально надо
Люди используют то, что им удобно. Лёгкие бранчи и ненавязчивый мерж/ребэйз в svn тупо отсутствуют.
Здравствуйте, Sergey J. A., Вы писали:
.>>Хорошо. Сойдёмся на том, что для некоторых корявых легаси систем в некоторых случаях svn или zip в качестве vcs могут быть лучше. SJA>Если разницы между zip и svn не видно, то и смысла что-то обсуждать не вижу.
Разницы столько же как и между svn и git. А там уже от зрения зависит — кто что видит.
Шаг между CVCS и DVCS примерно такой же как и между бэкапами и VCS.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
D>Для более-менее честного тестирования импортируй svn в git ( git svn clone <svnurl> ) и гоняй тесты.
Чё-то не могу найти какой сервер можно запользовать. Обязательно чтоб умел аутентификацию и хотя бы базовую авторизацию. Желательно также чтоб легко инсталировался.
Есть такое на примете?
P.S. под винду
==
не актуально. вроде завёлся некий bonobo сервер
Здравствуйте, Sergey J. A., Вы писали:
SJA> D>Для более-менее честного тестирования импортируй svn в git ( git svn clone <svnurl> ) и гоняй тесты.
SJA> Чё-то не могу найти какой сервер можно запользовать. Обязательно чтоб умел аутентификацию и хотя бы базовую авторизацию. Желательно также чтоб легко инсталировался.
SJA> Есть такое на примете?
SJA> P.S. под винду
SJA> == SJA> не актуально. вроде завёлся некий bonobo сервер
Для чего сервер чтобы протестировать скорость работы с репозиторием git?
Здравствуйте, Dziman, Вы писали:
D>Для чего сервер чтобы протестировать скорость работы с репозиторием git?
Я ж хочу протестировать скорость в реальных условиях. Девелоперы обычно пушат свои изменения и пулят чужие.
Здравствуйте, Sergey J. A., Вы писали:
SJA> D>Для чего сервер чтобы протестировать скорость работы с репозиторием git?
SJA> Я ж хочу протестировать скорость в реальных условиях. Девелоперы обычно пушат свои изменения и пулят чужие.
Видимо ты всё-таки не понимаешь про какую скорость речь.
Здравствуйте, Dziman, Вы писали:
SJA>> Я ж хочу протестировать скорость в реальных условиях. Девелоперы обычно пушат свои изменения и пулят чужие.
D>Видимо ты всё-таки не понимаешь про какую скорость речь.
Поскольку равноценного аналога git commit в svn нет, то их и сравнивать особо незачем.
Буду сравнивать локальные операции — status, revert, diff
Сетевые операции pull/push — update/commit
Вот чекаут ещё сравню — в гите он просто реактивный, судя по всему.
