Здравствуйте, Centaur, Вы писали:

C>С кодировками имён файлов в git’е Всё Плохо. То есть всё хорошо под *nix’ами, а под Windows плохо. Это потому, что по юниксовой идеологии имена файлов священны и транскодировать их никак нельзя — пришла по протоколу байтовая строка, изволь передать её в функции работы с файлами как есть. А в Windows эти функции как раз работают в 866 или 1251.

Значит, плохо не только в git. В svn у нас, например, умельцы создавали такие имена файлов, которые не удавалось без потерь протолкнуть через дамп репозитария =) Хотя обычные русские имена — проходят. Баги, куда ж без них.

Slicer

SM>Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича.
Фича удобная, никто и не спорит, но создание ветки в SVN все-таки гемор .

Здравствуйте, Dym On, Вы писали:

SM>>Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича.
DO>Фича удобная, никто и не спорит, но создание ветки в SVN все-таки гемор .
Да ну бросьте же. Branch/Tag, ввели номер ревизии откуда гнуть, ввели название, поставили галочко внизу — и все. А как вам хотелось — чтоб за вас название придумали? =)

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>За курс молодого бойца — спасибо. Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича. Никто в твои изменения не лезет, а ты можешь постепенно ваять новую функцию хоть два дня, хоть неделю, хоть месяц. И как раз не нужно на локальном компе держать. К примеру, я сейчас в SVN каждый день прыгаю, как минимум, по 2 веткам в своем репозитарии еще иногда еще по одной в чужом. И еще по 1-2 своим собственным, отведенным на вялотекущие задачи сроком от нескольких дней до неопределенного.

SM>Спору нет, у git есть преимущества. Но и конкурентам предыдущего поколения не стоит придумывать новые недостатки сверх тех, которыми они и так страдают...

У SVN наконец заработал мердж с ветками? Раньше, насколько помню, беспроблемно влить изменения из мастера в свою ветку можно было ровно один раз — потом SVN начинал считать, что это я все сам придумал и предлагал разрешать конфликты для каждого из уже влитых изменений.

SM>А как вам хотелось — чтоб за вас название придумали? =)
Хотелось бы как в Git'е

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>У SVN наконец заработал мердж с ветками? Раньше, насколько помню, беспроблемно влить изменения из мастера в свою ветку можно было ровно один раз — потом SVN начинал считать, что это я все сам придумал и предлагал разрешать конфликты для каждого из уже влитых изменений.
Ну как... если честно вливать одни и те же изменения по несколько раз, мержилка может и не распознать дублирование. С другой стороны — а для чего несколько раз мержить одно и то же? Сначала залили коммиты до M-ного, в другой раз — c M+1-го по N-ный... Я обычно прям в коммите и пишу — слил такую-то ветку до такой-то ревизии.
Ну и потом, с какой-то версии они — чтобы не высматривать по логам, докуда мы уже успели слить — ввели запоминание истории сливов, чтобы можно было и на глаз видеть, что уже слито, а что нет, и автоматически тоже пропускать уже слитое. Хранится история в проперте svn:mergeinfo у конкретного сливаемого элемента (напр., сливаем "папочку" trunk — ей и пишется).

Slicer

Здравствуйте, Slicer [Mirkwood], Вы писали:

ТКС>>У SVN наконец заработал мердж с ветками? Раньше, насколько помню, беспроблемно влить изменения из мастера в свою ветку можно было ровно один раз — потом SVN начинал считать, что это я все сам придумал и предлагал разрешать конфликты для каждого из уже влитых изменений.
SM>Ну как... если честно вливать одни и те же изменения по несколько раз, мержилка может и не распознать дублирование. С другой стороны — а для чего несколько раз мержить одно и то же? Сначала залили коммиты до M-ного, в другой раз — c M+1-го по N-ный... Я обычно прям в коммите и пишу — слил такую-то ветку до такой-то ревизии.
SM>Ну и потом, с какой-то версии они — чтобы не высматривать по логам, докуда мы уже успели слить — ввели запоминание истории сливов, чтобы можно было и на глаз видеть, что уже слито, а что нет, и автоматически тоже пропускать уже слитое. Хранится история в проперте svn:mergeinfo у конкретного сливаемого элемента (напр., сливаем "папочку" trunk — ей и пишется).

Ну вот в этом и отличие — в гите просто переключаешься в свою ветку и забираешь изменения из последнего мастера (trunk), или любой другой ветки, хоть каждый день. Не забивая голову ненужными подробностями, и никаких левых конфликтов при этом не возникает. Собственно, насколько я понимаю, именно об этом речь и идет, когда говорят о легкой работе с ветками.

Здравствуйте, alvas, Вы писали:

A>

A>Я уже более десятка лет использую самые разные системы контроля версий, но за всё это время мною было создано веток меньше, чем при написании этой статьи.

A>А с этого места поподробней, пожалуйста

Что тут может быть подробнее? В svn бранчинг — это наказание и желательно его избегать. В git — развлечение. Такие вот побробности

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, alvas, Вы писали:

A>>

A>>Я уже более десятка лет использую самые разные системы контроля версий, но за всё это время мною было создано веток меньше, чем при написании этой статьи.

A>>А с этого места поподробней, пожалуйста

IT>Что тут может быть подробнее? В svn бранчинг — это наказание и желательно его избегать. В git — развлечение. Такие вот побробности

А я думал что ответ будет что-то типа: Когда я сел за написание этой статьи, то ... и давай расписывать как вы использовали git для написание этой статьи ...

Здравствуйте, Centaur, Вы писали:

C>... А пока стоит принять правило, что имена файлов должны вписываться в us-ascii. И путь к локальному репозиторию, кстати, тоже.

Да я обычно придерживаюсь этого правила, да тут невесть откуда завалялся файлик... А вообще, после переключения кодировки на windows-1251 проблема ушла. Я просто задумался — либо оставить кодировку, либо файлик переименовать...

Здравствуйте, adontz, Вы писали:


A>Хм. В меркуриале за апачем можно давать права доступа на отдельные папки, не только на репозиторий целиком. Но с другой строны, сам меркуриал поддерживает аутентицикацию.

С git-ом идёт скрипт update-paranoid. Так вот он при наличии нормальной аутентификации позволяет задавать права вплоть до веток. Причём как за апачем, так и за ssh.

Здравствуйте, ., Вы писали:

.>Да, афаик нельзя.
update-paranoid, gitosys, gitolite
.>А можно привести пример полезного юскейса для этого? Раньше в svn таким пользовался, но там папки по сути были независимые проекты для разных команд, и делалось это лишь потому, что так удобнее администрировать, чем плодить кучу репозиториев.

Ну например, так делается запрещение на удаление tag-ов, в master могут сливать только интеграторы, в topic-ветки может писать только програмер/его менеджер и т.п. Т.е. для поддержания целостности.

Здравствуйте, Roman Odaisky, Вы писали:

А>>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
RO>Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.
С чего бы это?

Здравствуйте, Roman Odaisky, Вы писали:

А>>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
RO>Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.

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

Здравствуйте, Slicer [Mirkwood], Вы писали:

SM>>>Но почему вы считаете, что создание веток в Subversion — гемор? Очень даже удобная фича.
DO>>Фича удобная, никто и не спорит, но создание ветки в SVN все-таки гемор .
SM>Да ну бросьте же. Branch/Tag, ввели номер ревизии откуда гнуть, ввели название, поставили галочко внизу — и все. А как вам хотелось — чтоб за вас название придумали? =)
Не всегда имеется возможность создать бранч самому, а здесь это "прошито" в дезайне.

Здравствуйте, IT, Вы писали:

IT>Здравствуйте, Roman Odaisky, Вы писали:

А>>>Вы не поверите, но большинство людей ждут именно картинок с указаниями куда смотреть и что жать в какой момент, т.е. чтобы вообще всё было разжовано и показано без особых пробелов.
RO>>Так RSDN (я тешу себя надеждой) отнюдь не представляет собой средоточие таких людей.

IT>Мне тоже кажется, что нет ничего плохого в том, чтобы снизить порог вхождения в технологию пусть даже теми же картинками.

Вообще, честь тебе и хвала в деле популяризации git-а. Ибо его считают каким-то шаманским сборником заклятий чОрной командной строки. А тут всё гламурненько. Помниться правда год назад GitExtention неилюзорно глючил, как, впрочем, и tortoriseHG . Базар в плане ГУИ хорошь из коробки и, кстати, может выступать просто удобным интерфейсом к svn-овскому репозиторию.

Романа я, правда, тоже понимаю ибо чОрной магии обучен хочется заклинаний левелом повыше.

Здравствуйте, dr.Chaos, Вы писали:

DC>Романа я, правда, тоже понимаю ибо чОрной магии обучен хочется заклинаний левелом повыше.

Да я и сам бывает заклинаниями балуюсь. Но всё по дилетантски — с вопросом в гугль, команду git в слипборд, Git bash прямо из тулбара Git Extensions, paste, edit, enter. Но такое бывает надо не часто

Здравствуйте, ., Вы писали:

.>Здравствуйте, AlexNek, Вы писали:

AN>> .>Ты можешь воспользоваться git svn для начала, поиграться самому, есть несколько подводных камней (надо бы это мне как-то рассказать на досуге), но почувствовать вкус вполне можно.
AN>> Но как я понял из описания — это просто синхронизатор двух репозиториев, да и еще с командной строкой
.>Да. В общем-то в любой совместной работе в гите ты синхронизируешь два репозитория. Если используешь git svn, то просто второй репозиторий — svn. Правда так как он довольно примитивный, приходится шаманить слегка.
.>Насчёт командной строки... там в общем-то всего 2 команды надо. По-мему в tortoisegit есть, но я ни разу не использовал.

Сколько нужно пока не знаю, но списки команд довольно приличные.
Кстати, решил сегодня попробовать git svn. Пока ничего отрицательного, но комп пришлось оставить включенным, оказывается в хеаде почти 79 тыс. файлов.
Кому еще захочется, вот пару ссылок
An introduction to git-svn for Subversion/SVK users and deserters
Downloads — msysgit — Git for Windows Говорят, что git svn есть только 3,4 ссылках.
Git Extensions | Download Git Extensions software

AN>> Вот нашел еще один огромный минус
AN>>

AN>> Основными достоинствами git (в сравнении с другими распределёнными системами контроля версий) в настоящее время принято считать:
AN>> * Unix-ориентированность и глубокий unixway во всём;

.>Эээ... оно не сильно отлчиается от svn.
Они вроде и есть но как то еще ни разу не попадались

AN>> .>В Идее есть суперская интеграция, есть tortoisegit, есть gitk, git gui, gitextensions... но я почему-то использую коммандную строку в большинстве случаев.
AN>> А что такое "Идея"? И что же лучше для студии исходя из того, что я ненавижу командные строки.
.>Jetbrains IDEA. Хз... дело вкуса. Надо пробовать самому.
Java IDE. Не... такое вообще не пробуем.

AN>> AN>> Также не совсем понятно как Гиту удается минимизировать конфликты.
AN>> .>Тем, что коммиты маленькие.
AN>> Так размер коммита зависит от программиста. Если для правки ошибки нужно исправить Х строк, так эти Х будут всегда.
.>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
.>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
Но получается только локально, а когда все закончил надо то в основную ветку забросить.

AN>> .>[делаем хотфикс обнаруженных багов]
AN>> .>git commit
AN>> .>git push

AN>>

AN>> вносим изменения в удаленный репозитарий (удаленную ветку)

AN>> А тут обломов не бывает?
.>Если кто-то что-то до тебя закоммитил, то при наличии конфликтов ругнётся, конечно. Будешь должен смержить или оставить мерж на потом.
.>Или что ты имеешь в виду под обломом?
Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать?

Здравствуйте, AlexNek, Вы писали:

AN> Сколько нужно пока не знаю, но списки команд довольно приличные.
AN> Кстати, решил сегодня попробовать git svn. Пока ничего отрицательного, но комп пришлось оставить включенным, оказывается в хеаде почти 79 тыс. файлов.
Да, есть такой момент... У меня один репозиторий с десятком тысяч ревизий и кучей бинарников (кто придумал скомпиленное коммитить?!) скачивался несколько дней...

AN> .>Эээ... оно не сильно отлчиается от svn.
AN> Они вроде и есть но как то еще ни разу не попадались
? Не понял.

AN> .>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
AN> .>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
AN> Но получается только локально, а когда все закончил надо то в основную ветку забросить.
Ну да, мержишь потом, сразу все коммиты. Притом история сохраняется (или не сохраняется, если решишь её поредактировать).

AN> Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать?
В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить.

Здравствуйте, ., Вы писали:

.>Здравствуйте, AlexNek, Вы писали:

.>(кто придумал скомпиленное коммитить?!)
Ээ.. у нас даже большая дискуссия была по этому поводу, прекратилась после первого неопознанного вылета

AN>> .>Эээ... оно не сильно отлчиается от svn.
AN>> Они вроде и есть но как то еще ни разу не попадались
.>? Не понял.
Ну команды для svn вроде есть, но как то в практике еще ни разу не попадались.

AN>> .>Нет. Если используешь svn, то перед тем как коммитить — надо точно знать, что коммитишь и не поломается ли чего у других.
AN>> .>При использовании git коммитишь когда завершаешь какую-то мысль. Т.е. например делаешь какую-то фичу. Чтобы её сделать — надо: что-то порефакторить, написать новый код, написать тест, добавить кнопки для новой фичи, поправить баги, дописать заглушки и т.п. Так вот коммитить можешь после каждого этапа.
AN>> Но получается только локально, а когда все закончил надо то в основную ветку забросить.
.>Ну да, мержишь потом, сразу все коммиты. Притом история сохраняется (или не сохраняется, если решишь её поредактировать).
Ну так когда сразу все коммиты, это равносильно svn коммит, в чем "качество" конфликтов будет отличаться?

AN>> Да конфиликты прежде всего. А если оставлю мерж на потом как же дальше работать?
.>В другой ветке. Ещё можно историю как-то поредактировать, чтобы количество конфликтов уменьшить.
Это как? Обнаружили конфликт, прерываем, берем все в новую ветку?

Кстати сегодня поигрался немного. Что выяснилось?
— Локальная копия взятая Гитом из svn и есть рабочий репозиторий гита.
— каталоги с пробелами или не ASCII символами гит не любит, хотя в Гит экстеншион показываются нормально.
— репозиторий гита весьма хорошо упакован
— обновления из svn ищутся быстрее черепахи.
— визуал Гит от Гит экстеншион не захотел грузится в мою 2008 студию
— ни в проводнике ни в Гит экстеншион нифига не видно состояний файла/папки (под контролем/модифицирован/не изменен)
— без коммандной строки нмфига не сделать. Добавил пару файлов в подконтрольный гиту каталог, еле нашел их в сташе. при попытке добавить в репозиторий получаю ошибку

C:\msysgit\cmd\git.cmd stash apply Current working dir changes
fatal: ambiguous argument 'Current': unknown revision or path not in the working tree.
use '--' to separate paths from revisions
Done

После получаса брожения по менюшкам и поиску ответа в сети Current заменился на какую то странную комбинацию и что то вроде пошло, но файлы упрямо не появлялись в Гит экстеншион пока не сделал все по описанным командам. При этом с проводника вообще ничего не получалось хотя и есть команда добавить файлы.

Так что пока отрицательных состояний больше чем положительных, но бум продолжать.