LINUX.ORG.RU

GNU Emacs перешёл с CVS на Bazaar

 , , , , ,


0

0

Один из старейших текстовых редакторов GNU Emacs сменил систему управления версиями с CVS на Bazaar. Переход на CVS проект осуществил ещё в 1993 году. Сейчас репозиторий CVS остаётся открытым в режиме «только для чтения».

Сообщение в почтовой рассылке от Карла Фогеля (Karl Fogel) >>>

Документация по переходу на Bazaar >>>

>>> Подробности

★★★★★

Проверено: maxcom ()
Ответ на: комментарий от gns

Походу, ты так и не посмотрел никуда %)

SVN command-line client — это пяток утилит и пара DLL (SlikSVN — 4.5Mb, ).

Mercurial CLI - 3.6метра.

Tourtoise-что-то поболе, конечно будет, Ну мегов в 20 впишется.

TortoiseHg (включая comman-line client) - 16метров. TortoiseSVN - ~18метров

Такая вот «тяжелая» исполняющая система у Mercurial...

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

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

Хотя если учесть что под вендой порой одни драйвера по 20-50 МБ бывают то еще 30-40 МБ пайтона не должно быть тяжелой ношей.

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

> Да нет же, он намекает на то, что с меркуриалом пайтон надо тащить

Определи понятие «пайтон тащить», а? Я Mercirial для венды видел в версии 0.9.чтото, и там был просто exe-файл и несколько zip.

то под вендой порой одни драйвера по 20-50 МБ бывают то еще 30-40 МБ пайтона не должно быть тяжелой ношей.

А еще учти, что минимальная инсталляха Git для венды - ~11метров. Так что не надо тут про размеры.

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

Во-первых это ты не нужен, раз не в состоянии уяснить, что название языка происходит не от пресмыкающихся, а от «Monty Python Flying Circus». Во-вторых он нужен поскольку по сравнению с другими языками он достаточно удобен, читаем и имеет хорошие, богатые библиотеки.

//Покормил...

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

>Определи понятие «пайтон тащить», а?

А точно, забыл! Там ведь для оффтопа создается единый бинарник довольно небольшого размера, так что у товарища либо SVN головного мозга, либо пайтонофобия ГМ.

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

>И кстати, Mercurial гораздо проще Git и в освоении, и в использовании.
Совершенно согласен.

Хотя, если не планируется многоуровневый комит, но хочется следовать моде, то у Базара, imo, проще организована работа с централизованным workflow.

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

>У него до этого VSS, а хотклось бы иметь ничего кроме Tourtuise-что-нибуть.
Ну так и переходите на SVN. У неё даже локи сделали, как у VSS чтобы массам проще перезжать было. Опыт перевода IT в Canada Broadcasting Corporation показал, что переход достаточно безболезненный.

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

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

> У неё даже локи сделали

В версии 1.2 (кажется), лет 5 назад %)

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

Ну питон я действительно как-то избегаю :)

И предпочитаю не таскать с собой универсальные интерпретаторы для выполнения одной задачи. Насчет SVN головного мозга — уж даже и не знаю. Я слишком давно за терминалом, — мне что дали, тем и пользуюсь :) Если все мои коллеги используют пневмомолоток для забивания гвоздей, то что у меня «пневмомолоток головного мозга»? Я работал с CVS, SVN, ClearCase и как-то не приходилось со всем остальным. Не потому что — брезгую, а потому что «так случилось». Поэтому, судя по тому, что систем контроля версий развелось чуть более, чем дохрена и все «примерно одинаковы», то выбор скорее «религиозен» или определяется наличием удобного инструментария для всех разработчиков/платформ коллектива. Ну и легкостью миграции.

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

Ну примерно так. Поэтому и слезая с CVS и смотрим на SVN. Не мне решать.

Хотя TortoiseHg тоже ничего :)

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

1) да, коммитишь, бранчишь и т.п. когда наступает время (по твоему решению) можешь свои наработки закоммитить - это одна команда - git svn dcommit. можешь явно получить изменения с помощью git svn rebase (без коммита твоих изменений)

2) git svn init svn-url.... потом git svn fetch, и все - ты можешь работать. при этом оно может втянуть все ветки и таги, и ты их можешь использовать в своей работе. например, удобно применять конкретный changeset к нужной ветке (через cherry pick), например, когда надо пофиксить и в development версии и в релизе

3) механизм работает нормально - у меня проблем с ним не было за 2 года использования...

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

> можешь свои наработки закоммитить - это одна команда - git svn dcommit

А если закоммитить что-нибудь сложнее линейной последовательности коммитов можно?

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

например?


SVN: r1--r2--r3------r4--r5--r6
      \    \          \
Git:   c1--c2--c3--c4--c5--c6 (и вот здесь я хочу сделать push)

Позволит ли git-svn операцию push, которая создает новую голову? Сохранит ли граф мержей (r2-c2, r4-c5)?

Или так:

SVN: r1--r2--r3--r4
      \
Git:   c1--c2--------c3 (и вот здесь я хочу сделать push)
           \        /
            c2.1--c2.2

создаст ли git-svn автоматически SVN-бранч для c2.1 и c2.2?

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

автоматически - не уверен, но можно явно сказать что создать бранч от такого-то changeset'а и закинуть туда соответствующие изменения. для первого случая, информация о merge сохраняется. я как раз начал использовать git-svn из-за того, что он лучше обрабатывал merge - у нас svn 1.4, поэтому часто были конфликты когда сливались изменения между несколькими ветками...

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

> автоматически - не уверен, но можно явно сказать что создать бранч от такого-то changeset'а и закинуть туда соответствующие изменения

Ну, вручную всё можно сделать...

А push. создающий новую голову, git-svn позволит?

для первого случая, информация о merge сохраняется. я как раз начал использовать git-svn из-за того, что он лучше обрабатывал merge - у нас svn 1.4

эээ... не понял. Я не спрашиваю о сохранении информации о мержах в Git - понятно, что он ее сохраняет. Интересно именно сохранение мержей в SVN (если сервер поддерживает), иначе твоему коллеге придется клонировать твой Git-репозиторий вместо импорта SVN. Фактически появятся 2 репозитория с разными VCS вместо единого SVN-репозитория.

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

да, все работает. про merge я просто хотел сказать, что git-svn иногда удобней, за счет того, что он умнее, но вся остальная информация в svn прокидывается...

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

А есть какая-то возможность сделать DVCS <-> VSS? Хотел бы попробовать локально что-нить типа Hg, но если придется потом вручную синхронизировать с VSS, придется отказаться, наверно.

JackyTreehorn
()

Ещё один проект на Питон перешёл...

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

> IMHO единственная здравая отмазка - можно работать в самолёте, когда нет связи с инетом.

Связи с сервером SVN может не быть, к сожалению, и при наличии инета.

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