| |
| 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 раза больше.
| | |
|
|
|
| |
| |
| 6.14, anonymous (??), 23:37, 23/12/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>а ну ка. особенно в сравнении с svn.
Нет докачки, неудобные номера ревизий, необходимость выкачивать всё дерево со всей историей, отсутствие официальной поддержки венды. Ещё?
| | |
| |
| 7.18, Аноним (-), 01:55, 24/12/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
*Нет докачки
Зачем? Или вы по gprs работаете?
*неудобные номера ревизий
Создание тегов никто не отменял.
*необходимость выкачивать всё дерево со всей историей
Это связано с тем, что это DVCS. К тому же это очень удобно, например можно сделать git blame:)
*отсутствие официальной поддержки венды
Под виндой работает.
У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая.
| | |
| 7.22, anonym (?), 04:53, 24/12/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
видимо ты не умеешь его готовить.
Во-первых, можно не брать все дерево, а только нужную ветку, во-вторых, глубину историю тоже можно указать, в-третьих он уже давненько официально поддерживает винду.
| | |
|
|
| 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 фичи: показывать себя в списке плагинов, удалять себя из списка плагинов. Остальное у него не получается совсем.
| | |
| |
| |
| 9.55, Аноним (-), 10:11, 25/12/2010 [^] [^^] [^^^] [ответить] | +/– | Видел как раз около месяца назад Оно не пригодно к использованию при http-досту... текст свёрнут, показать | | |
| |
| |
| |
| |
| 13.71, Аноним (-), 10:00, 27/12/2010 [^] [^^] [^^^] [ответить] | –1 +/– | А что, заставлять программеров пользоваться консолькой при каждом коммите синхро... текст свёрнут, показать | | |
|
|
|
|
|
|
| 7.53, Аноним (-), 20:23, 24/12/2010 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Как Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :)
При push не возникает конфликтов, потому что рабочий каталог и репозиторий - разные вещи. У упоротых авторов гит видимо на всё своё мнение.
> git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен.
Ну понятное дело, раз нету, значит не нужен.
| | |
| |
| |
| 9.70, Аноним (-), 03:54, 27/12/2010 [^] [^^] [^^^] [ответить] | +/– | Алгоритм абсолютно такой же как при наличии отдельного bare репозитория, только ... текст свёрнут, показать | | |
|
|
|
| 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.
| | |
| 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 достаточно разные задачи и масштабы, чтобы их объективно сравнивать.
просто долго было писать фразу "для целей -- совместной разработки программы" ..
думал что если уж написанно слово "программист" то и так ясно что реч идёт об программистской деятельности :-)
| | |
|
|
| |
| 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 достаточно сложен в изучении и бывает сложен в применении, но результат того _для меня_ стоит. Но не для ламера, надо быть хотя бы честным чайником.
> и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?"
Предпочитаю не задавать неоднозначных вопросов, чтоб не огорчаться ответами невпопад. :) Вы прекрасно озвучили проблему с наивным стилем вопрошания.
| | |
|
|
|
|
