The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Компания WANdisco намерена усовершенствовать Subversion

23.12.2010 20:54

Компания WANdisco, оплачивающая работу нескольких разработчиков Subversion и выпускающая на базе данной централизованной системы контроля версий несколько коммерческих продуктов, объявила о решении реализовать собственными силами пожелания, наиболее часто высказываемые пользователями Subversion, такие как функций по быстрому слиянию и созданию веток.

Результат работы планируется интегрировать в основную ветку исходных текстов Subversion и довести их до готовности до выхода релиза Subversion 1.7, который намечен на 2011 год. Работа будет проведена в тесном сотрудничестве с независимым сообществом разработчиков проекта Subversion, от которого будет зависеть конечное решение о включении созданных в WANdisco улучшений.

Некоторые из улучшений, которые намерена реализовать компания WANdisco:

  • Улучшение производительности выполнения операций по слиянию веток (merge) и реализация таких дополнительных функций, как возможность собрать все изменения, добавленные в одну ветку, и применить их к другой ветке;
  • Реализация механизма отслеживания переименований файлов в репозитории, позволяющего исключить конфликты в процессе слияния веток при изменении имен файлов (т.е. при слиянии изменения определенного файла из одной ветки будут применены к этому же файлу в другой ветке, даже если файл во второй ветке был переименован);
  • Усовершенствование реализации команды 'svn import' в плане улучшенной поддержки непрерывного импорта стороннего кода в разные ветки репозитория. Улучшение окажется полезным прежде всего разработчикам, вынужденным отслеживать и обновлять в своем проекте код от сторонних производителей, например, когда созданный внешним поставщиком код один раз импортируется, а потом периодически обновляется в репозитории.
  • Переработка архитектуры модуля аутентификации mod_authz в более гранулированный вид, напоминающий классическую систему разграничения доступа к файлам в Unix;
  • Поддержка предписанной репозиторием конфигурации (repository-dictated);
  • Улучшение корректности работы команды "svn blame -g", при формировании вывода которой будет просмотрена вся история слияний и отслежены все авторы, участвующего в слияниях кода.

Из ранее отмеченных планов по развитию Subversion можно отметить:

  • Возможность реального удаления данных из репозитория (операция delete только помечает данные удаленными, физически оставляя их в репозитории);
  • Поддержка отложенных операций и контрольных точек;
  • Конфигурация, управляемая через репозиторий (Repository-dictated Configuration);
  • Отслеживание переименований;
  • Улучшение работы операции по слиянию веток;
  • Улучшение обработки конфликтов;
  • Поддержка промышленных механизмов аутентификации;
  • Возможность обратного поиска в истории;
  • Поддержка шаблонов для определения формата лога.

Напомним, что разработчики не намерены реализовывать в Subversion элементы распределенной системы управления версиями (DVCS), а сосредоточат свои усилия на развитии возможностей, связанных с организацией централизованных репозиториев, обеспечения жестких механизмов авторизации и гибких средств контроля доступа.

  1. Главная ссылка к новости (http://www.wandisco.com/php/pr...)
  2. OpenNews: Subversion влился в число первичных проектов Apache
  3. OpenNews: Компания WANdisco будет оплачивать работу трех разработчиков Subversion
  4. OpenNews: Доступен для загрузки Subversion 1.6.11. Планы на будущее
Лицензия: CC-BY
Тип: К сведению
Ключевые слова: svn, subversion, cvs
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (72) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Anonymous123 (?), 21:48, 23/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +10 +/
    Что только люди не придумают чтобы не пользоваться GIT
     
     
  • 2.2, stomp (??), 21:56, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +9 +/
    что только не придумают любители молока, чтобы не пить кока-колу
     
  • 2.3, anonymous (??), 21:58, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >Что только люди не придумают чтобы не пользоваться GIT

    Пользовались, спасибо. На редкость неудобная фигня.

     
     
  • 3.4, Аноним (-), 22:05, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Пользовались, спасибо. На редкость неудобная фигня.

    Это субъективное мнение. По мне так svn пора закопать и никогда больше не выкапывать.

     
     
  • 4.5, Alexey (??), 22:24, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Т.е. ваше мнение объективное, а у остальных субъективное? У Subversion есть своя ниша с которой его вряд ли выковырять распределенным системам.
     
     
  • 5.10, Ytch (?), 23:25, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >У Subversion есть своя ниша с которой его вряд ли выковырять распределенным системам.

    Потому что в этой нише он весьма удобен. Он создан для вполне определенной модели разработки. Для других моделей он в принципе не подходит (ни для кого не секрет, да?). Большинство распределенных систем, конечно, могут (кто больше, кто меньше) поддерживать аналогичную модель, но они РЕАЛЬНО сложней для неподготовленного (и не желающего становиться таковым!) пользователя, а таких пользователей весьма немало!
    Основной плюс svn, это то, что он вытесняет cvs! Работать с svn после cvs - это просто праздник (вроде и аналогично все, но как-то стройнее и лучше вся система получается). Собственно, какой смысл сравнивать SVN и разные DVCS, если они принципиально разные и предназначены для разного?
    Даже сравнивать основные DVCS между собой не имеет большого смысла (для задач общего назначения, как минимум), поскольку, в настоящее время, все заканчивается аргументами типа "нравится/не нравится", которые базируются на мнениях типа "2 года назад пробовал - не порадовало". Все что есть в одной уже давно есть в других, как минимум в виде плагинов или даже как штатные функции начиная с версии N. Например, даже bazaar, на сегодняшний день, умеет НЕ создавать отдельные директории для веток несмотря на основную свою парадигму (почему-то это до сих пор ставят ему как основной недостаток), да и git уже худо-бедно справляется с кириллицей и перемещениями файлов и папок (что непременно ставят в укор ему). Список можно продолжать очень долго...

     
     
  • 6.25, iZEN (ok), 07:29, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Основной плюс svn, это то, что он вытесняет cvs!

    Пробовал как пользователь использовать SVN для синхронизации исходников FreeBSD. Не понравилось то, что на диске каталог /usr/src занимал почти в три раза больше места, чем чистовой каталог, синхронизированный CVS. В чём преимущества SVN перед CVS для себя так и не уяснил.

     
     
  • 7.27, anonymous (??), 08:13, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А что скажет по этому поводу Калтенбруннер^Wрядовой разработчик FreeBSD? Сдается мне, что после парочки-тройки чекаутов/мержев/масштабных коммитов из CVS и SVN для себя он сделает далеко идущие выводы.
     
  • 7.29, QuAzI (ok), 08:21, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Где-то видел, ребята писали что наложили свой софт на порты FreeBSD. Но с SVN у них это не получалось, пришлось именно Subversion курить для этих целей. У них получился репозитарий портов в котором и порты FreeBSD и ихние порты. Они обновляют порты их репозитария FreeBSD и при этом там остаются ихние порты. Что-то в этом духе. Надо поискать, перечитать.
     
     
  • 8.56, volax (?), 12:37, 25/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    http code google com p bsd-sharp downloads list Там несколько методов заливки,... текст свёрнут, показать
     
  • 7.30, Аноним (-), 09:10, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +4 +/
    У CVS же не атомарные коммиты. Оборвалась связь во время коммита - получишь половину закомичено, половина - нет.
     
  • 7.43, rymis (?), 12:20, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    svn revert и svn diff не обращаются к серверу, в .svn лежат исходные файлы, поэтому и размер минимум в 2 раза больше.
     
  • 4.8, anonymous (??), 22:40, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Это субъективное мнение.

    Недостатки git вполне объективны.

     
     
  • 5.11, Mike Lee (?), 23:25, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    а ну ка. особенно в сравнении с svn.
     
     
  • 6.14, anonymous (??), 23:37, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >а ну ка. особенно в сравнении с svn.

    Нет докачки, неудобные номера ревизий, необходимость выкачивать всё дерево со всей историей, отсутствие официальной поддержки венды. Ещё?

     
     
  • 7.18, Аноним (-), 01:55, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    *Нет докачки
    Зачем? Или вы по gprs работаете?
    *неудобные номера ревизий
    Создание тегов никто не отменял.
    *необходимость выкачивать всё дерево со всей историей
    Это связано с тем, что это DVCS. К тому же это очень удобно, например можно сделать git blame:)
    *отсутствие официальной поддержки венды
    Под виндой работает.

    У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая.

     
     
  • 8.20, Аноним (-), 03:08, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    именно поэтому mercurial те же яйца, только проще и адекватнее... текст свёрнут, показать
     
  • 8.32, Аноним (-), 09:12, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Для каждого комита делать тег Вы в своём уме ... текст свёрнут, показать
     
  • 8.35, anonymous (??), 10:08, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    256-и мегабитный анлим qt обновить невозможно, если недельку не делать git pull... текст свёрнут, показать
     
     
  • 9.37, Mike Lee (?), 10:13, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вы его по http чтоли делаете откройте для себя уже более другие протоколы а чт... текст свёрнут, показать
     
     
  • 10.39, Аноним (-), 10:23, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что, для git уже написан мануал по прикручиванию всевозможных auth На оффс... текст свёрнут, показать
     
     
  • 11.41, anonymous (??), 11:19, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Какое отношение имеют твои комплексы к git Мы уже поняли, что ты ретроград ... текст свёрнут, показать
     
     
  • 12.48, Аноним (-), 17:57, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Человеческий мануал вместо RTFSC - уже ретроградство Вы там со своим житом со... текст свёрнут, показать
     
  • 11.49, Crazy Alex (??), 18:05, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    git используется для анонимного доступа Для обновить qt - в самый раз Для... текст свёрнут, показать
     
  • 10.44, anonymous (??), 13:05, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что, другие протоколы добавляют в git поддержку докачки А что, разработчик до... текст свёрнут, показать
     
     
  • 11.45, OramahMaalhur (ok), 13:47, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    куча svn директорий во всевозможных папках - да, это мечта _ ... текст свёрнут, показать
     
  • 7.22, anonym (?), 04:53, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    видимо ты не умеешь его готовить.
    Во-первых, можно не брать все дерево, а только нужную ветку, во-вторых, глубину историю тоже можно указать, в-третьих он уже давненько официально поддерживает винду.
     
     
  • 8.31, Аноним (-), 09:11, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Я работаю по gprs, когда сделают докачку ... текст свёрнут, показать
     
     
  • 9.34, Александр (??), 09:57, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    В распределенных системах контроля версий репозиторий хранится локально, поэтому... текст свёрнут, показать
     
     
  • 10.36, anonymous (??), 10:10, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А как же распределённость Вдруг там api поменяли, а я так и буду работать с уст... текст свёрнут, показать
     
  • 5.12, Ytch (?), 23:31, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> Это субъективное мнение.
    > Недостатки git вполне объективны.

    На git (такжк как и на svn) системы контроля версий не заканчиваются. Не подошел, по каким-то причинам, git, всегда можно попробовать что-то еще. Уж чего чего, а разных VCS в мире достаточно.

     
     
  • 6.15, anonymous (??), 23:41, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > На git (такжк как и на svn) системы контроля версий не заканчиваются.
    > Не подошел, по каким-то причинам, git, всегда можно попробовать что-то еще.
    > Уж чего чего, а разных VCS в мире достаточно.

    git не панацея. Если не нужна распределённость, то получается пшик на уровне cvs, если не хуже.

     
     
  • 7.58, Michael Shigorin (ok), 00:57, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да ладно сказки-то рассказывать.  У нас git и так тоже используют -- средства для того самого быстрого мержа _несравнимы_ с cvs-ными.  И при этом локально ветки разводить не в пример удобнее.

    SVN со своим подходом хорош в локалке индусских кодеров, где можно хоть голосом синхронизироваться -- кто что коммитит.  Ну или с IRC в паре, и то уже больно начинает быть.  Да, он подходит для workflow, когда "а больше ничего и не требуется" -- беда в том, когда workflow уже не масштабируется, а его всё пытаются растягивать (вместе с инструментом).

    Да, git сложней и менее вылизан в плане въезда (и особенно переезда головой с CVS).  Но это более осмысленное вложение времени для программиста (для кодера, пожалуй, нет): для локальной работы осваивается за четверть часа, а с распределённой довольно важно заметить git-remote(1) и не страдать ручными fetch'ами в локальные бранчи.

    В любом случае хорошо, что инструментарий для централизованного воркфорва тоже пилят :)

     
  • 4.47, bircoph (ok), 17:15, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    git не поддерживает:

    1) svn cp: сохранение истории при разделении файлов: был file.c, стало one.c и two.c — для одного из новых файлов история правок будет идти лишь с момента разделения file.c на два файла.

    2) svn import: git не позволяет импортировать кусок чужого проекта, не объявленный модулем, а svn — позволяет.

    3) в git нет прозрачной нумерации коммитов; что полезно для очень крупных проектов, раздражает на небольших.

     
     
  • 5.59, Michael Shigorin (ok), 01:04, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > git не поддерживает:
    > 1) svn cp: сохранение истории при разделении файлов

    google://git+copy+history =>
    http://markpasc.livejournal.com/186489.html?thread=556153#t556153

    > 2) svn import: git не позволяет импортировать кусок чужого проекта, не объявленный
    > модулем, а svn — позволяет.

    Хм, а зачем? (и ещё: git умеет обрабатывать ситуацию, когда один из подкаталогов сам является git repo -- возможно, это бы выручило)

    > 3) в git нет прозрачной нумерации коммитов; что полезно для очень крупных
    > проектов, раздражает на небольших.

    Какая может быть честная нумерация при распределёнке -- сколько ни думал, так и не придумал.  И заодно -- как с "прозрачной нумерацией", прибитой гвоздями, сделать что-нить вроде git rebase -i (ОСТОРОЖНО, оно острое!).

     
  • 3.9, Tav (ok), 23:05, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Тогда можно порекомендовать Mercurial. Он как git, только удобный (утрируя).
     
     
  • 4.13, Ytch (?), 23:35, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Тогда можно порекомендовать Mercurial. Он как git, только удобный (утрируя).

    Звучит как начало холивара :)
    git (на некоторых задачах, пока еще) быстрей, а bazaar (пока еще) удобней. Зачем mercurial?

     
     
  • 5.16, anonymous (??), 23:44, 23/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > git (на некоторых задачах, пока еще) быстрей

    Мне просто интересно, что это за задачи такие?


     
  • 5.19, Аноним (-), 01:55, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    bazaar вообще не рассматривается по причине маргинальности, а git до yблюдочности усложнён, а базовых вещей не умеет. Где push в не-bare репозиторий? Где git cp? И так далее. Лучше hg еще ничего не придумали.
     
     
  • 6.33, Аноним (-), 09:18, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > а базовых вещей не умеет. Где push в не-bare репозиторий? Где

    Как Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :)

    > git cp?

    git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен.

     
     
  • 7.38, Аноним (-), 10:18, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ок, готовый и полностью рабочий плагин для эклипса. Есть? По секрету: EGit - кривое поделие умеющее аж 2 фичи: показывать себя в списке плагинов, удалять себя из списка плагинов. Остальное у него не получается совсем.
     
     
  • 8.50, Crazy Alex (??), 18:11, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Рабораю с ним больше года В самом начале били каике-то чудеса, но очень давно ... текст свёрнут, показать
     
     
  • 9.55, Аноним (-), 10:11, 25/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Видел как раз около месяца назад Оно не пригодно к использованию при http-досту... текст свёрнут, показать
     
     
  • 10.60, Michael Shigorin (ok), 01:07, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    сочувственно Что, заставляют HTTP для git -- плохой транспорт, родной git ил... текст свёрнут, показать
     
     
  • 11.65, Аноним (-), 16:20, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так пусть Лунис Торвальц и напишет в главном man this project is a compilati... текст свёрнут, показать
     
     
  • 12.67, Michael Shigorin (ok), 17:42, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Давайте договоримся я его об этом попрошу, когда удостоверюсь в Вашей личности ... текст свёрнут, показать
     
     
  • 13.71, Аноним (-), 10:00, 27/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    А что, заставлять программеров пользоваться консолькой при каждом коммите синхро... текст свёрнут, показать
     
  • 11.66, Аноним (-), 17:39, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    А впрочем, какая разница, что для гита консольного является плохим транспортом... текст свёрнут, показать
     
  • 7.53, Аноним (-), 20:23, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Как Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :)

    При push не возникает конфликтов, потому что рабочий каталог и репозиторий - разные вещи. У упоротых авторов гит видимо на всё своё мнение.

    > git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен.

    Ну понятное дело, раз нету, значит не нужен.

     
     
  • 8.61, Michael Shigorin (ok), 01:14, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Вот только состояние верхушки той ветки репо git , куда пушили, и чекаутнутой... текст свёрнут, показать
     
     
  • 9.70, Аноним (-), 03:54, 27/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Алгоритм абсолютно такой же как при наличии отдельного bare репозитория, только ... текст свёрнут, показать
     
     
  • 10.73, Michael Shigorin (ok), 13:20, 27/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ясно, слабо _Это_ действительно очевидно PS какой-такой отдельный bare repo... текст свёрнут, показать
     
     
  • 11.74, Аноним (-), 19:52, 28/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Ты как всегда в своем троллеламерском стиле при нормальном дизайне VCS working... текст свёрнут, показать
     
     
  • 12.76, Michael Shigorin (ok), 20:41, 28/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    С зеркалом закончите разговаривать, сообщите Озвучьте критерии нормального ... текст свёрнут, показать
     
  • 6.57, Ytch (?), 14:26, 25/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >bazaar вообще не рассматривается по причине маргинальности

    А вот это по-настоящему серьезный, сугубо технический и объективный аргумент! Надо бы этот параметр обязательно включать во все бенчмарки любых систем!

     
     
  • 7.75, Аноним (-), 19:56, 28/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > А вот это по-настоящему серьезный, сугубо технический и объективный аргумент!

    Вообще-то это нормальный аргумент. Причём объединяет в себе как причины, так и следствия убогости базара. Был бы хорошей VCS - был бы распространён чуть шире чем нигде это следствие. А причина - зачем ставить левоту когда везде есть и уже используются git/hg?

     
  • 5.23, kshetragia (ok), 06:24, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Как минимум там адекватная система команд. Не сношающая мозг после перехода с CVS/SVN
     

  • 1.6, gegMOPO4 (ok), 22:26, 23/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Революционных изменений нет -- и это плохо.
    Революционных изменений нет -- и это хорошо.

    Просто мелкие улучшения. А вот вкусные вещи (Shelve/Checkpoint, Repository-dictated Configuration) отложены до 1.8.

     
     
  • 2.24, kshetragia (ok), 06:25, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    Да уж.. Адекватный merge - такая мелочь..
     

  • 1.7, Пользователь Debian (?), 22:26, 23/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Эти ребятки даже опускались до тупого пиара в тематических конференциях -- пример: http://groups.google.com/group/git-users/browse_thread/thread/fc4c0c05dc22f53

    Так что закапывайте их вместе с Subversion.

     
  • 1.17, Аноним123321 (ok), 01:24, 24/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    хорошо что в Git/Mercurial/Bazaar -- есть слои совместимости с SVN ...

    ...ато ведь SVN-программисты будут до скончания века говорить что "svn самая удобная штука на свете, и альтернатив её нет"

    бороться бесполезно :-)

     
     
  • 2.26, k0l0b0k (??), 07:50, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    >...ато ведь XXX-программисты будут до скончания века говорить что "xxx самая удобная штука на свете, и альтернатив её нет"

    вместо XXX подставляйте что угодно, хоть git, хоть mercurial, хоть bazaar...
    доказательство см. выше - каждый хоть раз в жизни сделавший git pull считает прямо-таки своим долгом обгадить svn. При этом не задумываясь, что у vcs и dvcs достаточно разные задачи и масштабы, чтобы их объективно сравнивать.
    не было еще птички, которая вылетела из гнезда не обгадив его.

     
     
  • 3.68, Имя111223 (?), 01:16, 27/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > При этом не задумываясь, что у vcs и dvcs достаточно разные задачи и масштабы, чтобы их объективно сравнивать.

    просто долго было писать фразу "для целей -- совместной разработки программы" ..

    думал что если уж написанно слово "программист" то и так ясно что реч идёт об программистской деятельности :-)

     

  • 1.21, Аноним (-), 03:23, 24/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот сначала бы сделали, а потом бы хвастались!
     
     
  • 2.28, anonymous (??), 08:18, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > Вот сначала бы сделали, а потом бы хвастались!

    Вообще-то, это нормальная практика анонсировать то, что хочешь сделать. Чтобы потом толпы хомячков не слали разработчикам лучи добра и счастья.

     

  • 1.51, Аноним (-), 18:49, 24/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Комменты доставляют. Сначала использовал svn, долго ненавидел git. Теперь же не понимаю, как можно использовать что-то ещё кроме git. И вот надо же, если бы я увидел это год назад, подумал что и правду git не стоит потраченных усилий. Как хорошо что год назад вас не было, дорогие анонимусы.
     
     
  • 2.52, stomp (??), 19:57, 24/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    пользовался и svn, и git годами. второй годится разве что для kernel.org-подобных проектов, где все данные проходят через одного человека-тирана (он как раз и выполняет те функции централизации в DVCS, которые в централизованных VCS являются частью дизайна). для прозрачной слаженной командной работы svn подходит лучше
     
     
  • 3.64, Michael Shigorin (ok), 14:21, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > пользовался и svn, и git годами. второй годится разве что для kernel.org-подобных
    > проектов, где все данные проходят через одного человека-тирана (он как раз
    > и выполняет те функции централизации в DVCS, которые в централизованных VCS
    > являются частью дизайна). для прозрачной слаженной командной работы svn подходит лучше

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

    IMHO svn лучше подходит для слаженного кодирования разве что.  И притом _требует_ слаженности, планирования и возможности оперативного взаимодействия при внесении изменений.  Для кого-то такая внешняя дисциплина (как и питоний синтаксически значимый whitespace) -- нужна.  А для кого-то это неразумная и контрпродуктивная помеха, потому что человек опытней тех, на кого ориентировано такое менторство инструмента.

    Собсно не надо выдавать достоинства и недостатки _workflow_ за таковые _инструмента_.

     

  • 1.62, Аноним (-), 11:20, 26/12/2010 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    я не кодер... просто занимаюсь поддержкой(в плане сборки тестовых пакетов для Linux-base)... и могу сказать что Git менее удобен чем SVN..
    даже в плане таких простых операций, как удаленный запрос номера ревизии и скачивание конкретно заданной ревизии(не говоря уж о том что в Git и понятия такого внятного нет, какой-то паранойдальный хеш)
     
     
  • 2.63, Michael Shigorin (ok), 14:16, 26/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > я не кодер... просто занимаюсь поддержкой

    Ну так и не судите инструмент _разработчика_. :)  Я и пакеты собираю из гита, чем по большей части _уже_ доволен.

    > даже в плане таких простых операций, как удаленный запрос номера ревизии

    Поясните, какой ожидается результат запроса -- может, что соображу.

    > и скачивание конкретно заданной ревизии

    Если нужен снапшот -- обычно у проектов есть gitweb, а он даёт взять тарбол, соответствующий коммиту. (и историю там же может быть удобней глянуть краем глаза)

    >(не говоря уж о том что в Git и понятия такого внятного нет,
    >какой-то паранойдальный хеш)

    Ещё раз: он не "параноидальный", а отражает тот факт, что диффы и история изменений -- вещи необязательно связанные намертво.

    Например, есть у меня foo.c и bar.h; правлю foo.c и делаю один коммит; правлю их оба (foo.c в другом месте, т.е. правки не пересекаются) и делаю второй коммит.

    Внимание, вопрос: зачем какие-то искусственные ревизии, если может быть лучше (например, из соображений читабельности) перед публикацией эти коммиты поменять местами?  Изменения те же, результат -- тот же, а вот порядок изменился. (пресловутый git rebase --interactive и такое позволяет делать)

    Вообще рекомендую почитать при удобном случае вот эту статью: http://tomayko.com/writings/the-thing-about-git -- там разбирается как раз то, что git не вколачивает свой единственный правильный workflow в глотку пользователя ("и только мне попробуй шелохнуться!"), а предоставляет возможность наработать свой, удобный человеку.

    Да, это сложнее, как и любое творчество сложнее хождения строем.  И времени больше надо.  Но это не недостаток инструмента -- а либо про него Вам наврали, что "простой" (он не простой), либо есть желание уж лучше ходить строем (что дело личное).

     
     
  • 3.69, Имя111223 (?), 01:27, 27/12/2010 [^] [^^] [^^^] [ответить]  
  • +/
    > ...а либо про него Вам наврали, что "простой" (он не простой), либо ...

    "простой для изучения" и "простой для использования" -- это немного разные понятия

    инструмент зачастую бывает простой для использования -- но СЛОЖНЫЙ для изучения!!

    ----------

    ..наглядный пример: КАРАНДАШ!

    карандошом легко писать слова (но это когда вы уже _научились_ правильно пользоваться карандошом)..

    ....но вспомните -- сколько требуется времени и усилий человеку чтобы овладеть навыком использования карандаша (для написания слов)!!! :-)

    времени явно больше чем время что требуется на изучение Git :-) :-)

    ----------

    и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?" что вы ожидаете услышать? ответ на тему того что инстурмент простой для обучения? или что инструмент просто для повседневной работы?

     
     
  • 4.72, Michael Shigorin (ok), 13:19, 27/12/2010 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >> ...а либо про него Вам наврали, что "простой" (он не простой), либо ...
    > "простой для изучения" и "простой для использования" -- это немного разные понятия

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

    > и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?"

    Предпочитаю не задавать неоднозначных вопросов, чтоб не огорчаться ответами невпопад. :)  Вы прекрасно озвучили проблему с наивным стилем вопрошания.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру