Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Компания WANdisco намерена усовершенствовать Subversion"	+/–
Сообщение от opennews (?), 23-Дек-10, 21:48
Компания WANdisco, оплачивающая работу нескольких разработчиков Subversion и выпускающая на базе данной централизованной системы контроля версий несколько коммерческих продуктов, объявила (http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20) о решении реализовать собственными силами пожелания, наиболее часто высказываемые пользователями Subversion, такие как функций по быстрому слиянию и созданию веток. Результат работы планируется интегрировать в основную ветку исходных текстов Subversion и довести их до готовности до выхода релиза Subversion 1.7, который намечен на 2011 год. Работа будет проведена (http://blogs.wandisco.com/2010/12/20/shaking-up-subversion-b.../) в тесном сотрудничестве с независимым сообществом разработчиков проекта Subversion, от которого будет зависеть конечное решение о включении созданных в WANdisco улучшений. Некоторые из улучшений (http://www.wandisco.com/svndisco), которые намере... URL: http://www.wandisco.com/php/pr.php?rss=0&prdate=2010-12-20 Новость: http://www.opennet.dev/opennews/art.shtml?num=29107
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Anonymous123 (?), 23-Дек-10, 21:48	+10 +/–
Что только люди не придумают чтобы не пользоваться GIT
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3

2. Сообщение от stomp (??), 23-Дек-10, 21:56	+9 +/–
что только не придумают любители молока, чтобы не пить кока-колу
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

3. Сообщение от anonymous (??), 23-Дек-10, 21:58	+7 +/–
>Что только люди не придумают чтобы не пользоваться GIT Пользовались, спасибо. На редкость неудобная фигня.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #4, #9

4. Сообщение от Аноним (-), 23-Дек-10, 22:05	+3 +/–
> Пользовались, спасибо. На редкость неудобная фигня. Это субъективное мнение. По мне так svn пора закопать и никогда больше не выкапывать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #5, #8, #47

5. Сообщение от Alexey (??), 23-Дек-10, 22:24	+9 +/–
Т.е. ваше мнение объективное, а у остальных субъективное? У Subversion есть своя ниша с которой его вряд ли выковырять распределенным системам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #10

6. Сообщение от gegMOPO4 (ok), 23-Дек-10, 22:26	+/–
Революционных изменений нет -- и это плохо. Революционных изменений нет -- и это хорошо. Просто мелкие улучшения. А вот вкусные вещи (Shelve/Checkpoint, Repository-dictated Configuration) отложены до 1.8.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

7. Сообщение от Пользователь Debian (?), 23-Дек-10, 22:26	+2 +/–
Эти ребятки даже опускались до тупого пиара в тематических конференциях -- пример: http://groups.google.com/group/git-users/browse_thread/threa... Так что закапывайте их вместе с Subversion.
Ответить | Правка | Наверх | Cообщить модератору

8. Сообщение от anonymous (??), 23-Дек-10, 22:40	+/–
> Это субъективное мнение. Недостатки git вполне объективны.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #11, #12

9. Сообщение от Tav (ok), 23-Дек-10, 23:05	+5 +/–
Тогда можно порекомендовать Mercurial. Он как git, только удобный (утрируя).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #3 Ответы: #13

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

11. Сообщение от Mike Lee (?), 23-Дек-10, 23:25	+2 +/–
а ну ка. особенно в сравнении с svn.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #14

12. Сообщение от Ytch (?), 23-Дек-10, 23:31	+1 +/–
>> Это субъективное мнение. > Недостатки git вполне объективны. На git (такжк как и на svn) системы контроля версий не заканчиваются. Не подошел, по каким-то причинам, git, всегда можно попробовать что-то еще. Уж чего чего, а разных VCS в мире достаточно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #15

13. Сообщение от Ytch (?), 23-Дек-10, 23:35	+2 +/–
> Тогда можно порекомендовать Mercurial. Он как git, только удобный (утрируя). Звучит как начало холивара :) git (на некоторых задачах, пока еще) быстрей, а bazaar (пока еще) удобней. Зачем mercurial?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9 Ответы: #16, #19, #23

14. Сообщение от anonymous (??), 23-Дек-10, 23:37	–1 +/–
>а ну ка. особенно в сравнении с svn. Нет докачки, неудобные номера ревизий, необходимость выкачивать всё дерево со всей историей, отсутствие официальной поддержки венды. Ещё?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #18, #22

15. Сообщение от anonymous (??), 23-Дек-10, 23:41	+/–
> На git (такжк как и на svn) системы контроля версий не заканчиваются. > Не подошел, по каким-то причинам, git, всегда можно попробовать что-то еще. > Уж чего чего, а разных VCS в мире достаточно. git не панацея. Если не нужна распределённость, то получается пшик на уровне cvs, если не хуже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #58

16. Сообщение от anonymous (??), 23-Дек-10, 23:44	+/–
> git (на некоторых задачах, пока еще) быстрей Мне просто интересно, что это за задачи такие?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

17. Сообщение от Аноним123321 (ok), 24-Дек-10, 01:24	+/–
хорошо что в Git/Mercurial/Bazaar -- есть слои совместимости с SVN ... ...ато ведь SVN-программисты будут до скончания века говорить что "svn самая удобная штука на свете, и альтернатив её нет" бороться бесполезно :-)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #26

18. Сообщение от Аноним (-), 24-Дек-10, 01:55	–1 +/–
*Нет докачки Зачем? Или вы по gprs работаете? *неудобные номера ревизий Создание тегов никто не отменял. *необходимость выкачивать всё дерево со всей историей Это связано с тем, что это DVCS. К тому же это очень удобно, например можно сделать git blame:) *отсутствие официальной поддержки венды Под виндой работает. У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #20, #32, #35

19. Сообщение от Аноним (-), 24-Дек-10, 01:55	+1 +/–
bazaar вообще не рассматривается по причине маргинальности, а git до yблюдочности усложнён, а базовых вещей не умеет. Где push в не-bare репозиторий? Где git cp? И так далее. Лучше hg еще ничего не придумали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #33, #57

20. Сообщение от Аноним (-), 24-Дек-10, 03:08	+2 +/–
>У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая. именно поэтому mercurial. те же яйца, только проще и адекватнее
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

21. Сообщение от Аноним (-), 24-Дек-10, 03:23	+/–
Вот сначала бы сделали, а потом бы хвастались!
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

22. Сообщение от anonym (?), 24-Дек-10, 04:53	+1 +/–
видимо ты не умеешь его готовить. Во-первых, можно не брать все дерево, а только нужную ветку, во-вторых, глубину историю тоже можно указать, в-третьих он уже давненько официально поддерживает винду.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #31

23. Сообщение от kshetragia (ok), 24-Дек-10, 06:24	+/–
Как минимум там адекватная система команд. Не сношающая мозг после перехода с CVS/SVN
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

24. Сообщение от kshetragia (ok), 24-Дек-10, 06:25	+/–
Да уж.. Адекватный merge - такая мелочь..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6

25. Сообщение от iZEN (ok), 24-Дек-10, 07:29	+/–
> Основной плюс svn, это то, что он вытесняет cvs! Пробовал как пользователь использовать SVN для синхронизации исходников FreeBSD. Не понравилось то, что на диске каталог /usr/src занимал почти в три раза больше места, чем чистовой каталог, синхронизированный CVS. В чём преимущества SVN перед CVS для себя так и не уяснил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #27, #29, #30, #43

26. Сообщение от k0l0b0k (??), 24-Дек-10, 07:50	+/–
>...ато ведь XXX-программисты будут до скончания века говорить что "xxx самая удобная штука на свете, и альтернатив её нет" вместо XXX подставляйте что угодно, хоть git, хоть mercurial, хоть bazaar... доказательство см. выше - каждый хоть раз в жизни сделавший git pull считает прямо-таки своим долгом обгадить svn. При этом не задумываясь, что у vcs и dvcs достаточно разные задачи и масштабы, чтобы их объективно сравнивать. не было еще птички, которая вылетела из гнезда не обгадив его.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #17 Ответы: #68

27. Сообщение от anonymous (??), 24-Дек-10, 08:13	+1 +/–
А что скажет по этому поводу Калтенбруннер^Wрядовой разработчик FreeBSD? Сдается мне, что после парочки-тройки чекаутов/мержев/масштабных коммитов из CVS и SVN для себя он сделает далеко идущие выводы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

28. Сообщение от anonymous (??), 24-Дек-10, 08:18	+/–
> Вот сначала бы сделали, а потом бы хвастались! Вообще-то, это нормальная практика анонсировать то, что хочешь сделать. Чтобы потом толпы хомячков не слали разработчикам лучи добра и счастья.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

29. Сообщение от QuAzI (ok), 24-Дек-10, 08:21	–3 +/–
Где-то видел, ребята писали что наложили свой софт на порты FreeBSD. Но с SVN у них это не получалось, пришлось именно Subversion курить для этих целей. У них получился репозитарий портов в котором и порты FreeBSD и ихние порты. Они обновляют порты их репозитария FreeBSD и при этом там остаются ихние порты. Что-то в этом духе. Надо поискать, перечитать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #56

30. Сообщение от Аноним (-), 24-Дек-10, 09:10	+4 +/–
У CVS же не атомарные коммиты. Оборвалась связь во время коммита - получишь половину закомичено, половина - нет.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

31. Сообщение от Аноним (-), 24-Дек-10, 09:11	+/–
> видимо ты не умеешь его готовить. > Во-первых, можно не брать все дерево, а только нужную ветку, во-вторых, глубину > историю тоже можно указать, в-третьих он уже давненько официально поддерживает винду. Я работаю по gprs, когда сделают докачку?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #34

32. Сообщение от Аноним (-), 24-Дек-10, 09:12	+/–
> *неудобные номера ревизий > Создание тегов никто не отменял. Для каждого комита делать тег? Вы в своём уме?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18

33. Сообщение от Аноним (-), 24-Дек-10, 09:18	+1 +/–
> а базовых вещей не умеет. Где push в не-bare репозиторий? Где Как Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :) > git cp? git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #38, #53

34. Сообщение от Александр (??), 24-Дек-10, 09:57	+/–
В распределенных системах контроля версий репозиторий хранится локально, поэтому инет нужен очень редко (только для скачивания и отправки новых changeset'ов, при этом коммитов можно сделать хоть сколько - для этого инет не нужен). Если вам кому-то нужно (не в центральный репозиторий) отпавить свои изменения, и при этом у вас плохая связь, то вы можете это сделать хоть по фтп, хоть через емайл, предварительно сформировав bundle с изменениями.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #31 Ответы: #36

35. Сообщение от anonymous (??), 24-Дек-10, 10:08	–1 +/–
>Зачем? Или вы по gprs работаете? 256-и мегабитный анлим. qt обновить невозможно, если недельку не делать git pull. >Создание тегов никто не отменял. Для каждого коммита? >Это связано с тем, что это DVCS. К тому же это очень удобно, например можно сделать git blame:) Ну понятно, кактус он такой вкусный. >Под виндой работает. Ссылочку, пожалуйста. >У git есть большой недостаток - он сложнее, чем svn, кривая обучения у git слишком крутая. На да, git для гениев с 16 мегабитным анлимом. Я знаю.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #37

36. Сообщение от anonymous (??), 24-Дек-10, 10:10	+/–
> В распределенных системах контроля версий репозиторий хранится локально, поэтому инет нужен очень редко (только для скачивания и отправки новых changeset'ов, при этом коммитов можно сделать хоть сколько - для этого инет не нужен). А как же распределённость? Вдруг там api поменяли, а я так и буду работать с устаревшим кодом?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

37. Сообщение от Mike Lee (?), 24-Дек-10, 10:13	+1 +/–
> 256-и мегабитный анлим. qt обновить невозможно, если недельку не делать git pull. вы его по http чтоли делаете? откройте для себя уже более другие протоколы. > Для каждого коммита? а что, каждый коммит кому то нужен кроме разработчика? >Ну понятно, кактус он такой вкусный. ну да, вы ж пользуетесь svn
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35 Ответы: #39, #44

38. Сообщение от Аноним (-), 24-Дек-10, 10:18	–2 +/–
Ок, готовый и полностью рабочий плагин для эклипса. Есть? По секрету: EGit - кривое поделие умеющее аж 2 фичи: показывать себя в списке плагинов, удалять себя из списка плагинов. Остальное у него не получается совсем.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #50

39. Сообщение от Аноним (-), 24-Дек-10, 10:23	–1 +/–
>> 256-и мегабитный анлим. qt обновить невозможно, если недельку не делать git pull. >вы его по http чтоли делаете? откройте для себя уже более другие протоколы. А что, для git:// уже написан мануал по прикручиванию всевозможных auth? На оффсайте? Ссылку же, срочно! Желательно не Basic, а, как минимум Digest-MD5, или подобное. А если http не годно, зачем прямо в дистрибе идет враппер для всяких апачей? "Мы умеем 100500 разных штук, но ни одну не умеем хорошо"? И да, даже по DAV оно получилось отвратным г-ном, но об этом я писал ниже - EGit не умеет ничего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #41, #49

41. Сообщение от anonymous (??), 24-Дек-10, 11:19	+1 +/–
Какое отношение имеют твои комплексы к git? Мы уже поняли, что ты ретроград.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39 Ответы: #48

43. Сообщение от rymis (?), 24-Дек-10, 12:20	+/–
svn revert и svn diff не обращаются к серверу, в .svn лежат исходные файлы, поэтому и размер минимум в 2 раза больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25

44. Сообщение от anonymous (??), 24-Дек-10, 13:05	–1 +/–
>вы его по http чтоли делаете? откройте для себя уже более другие протоколы. А что, другие протоколы добавляют в git поддержку докачки? >а что, каждый коммит кому то нужен кроме разработчика? А что, разработчик должен обладать 16-и мегабитным без вариантов? А так я и тарбол по ftp скачаю. Нафиг мне гит? >ну да, вы ж пользуетесь svn Да, после гита это просто сказка.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #45

45. Сообщение от OramahMaalhur (ok), 24-Дек-10, 13:47	+2 +/–
куча .svn директорий во всевозможных папках - да, это мечта >_<
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от bircoph (ok), 24-Дек-10, 17:15	+2 +/–
git не поддерживает: 1) svn cp: сохранение истории при разделении файлов: был file.c, стало one.c и two.c — для одного из новых файлов история правок будет идти лишь с момента разделения file.c на два файла. 2) svn import: git не позволяет импортировать кусок чужого проекта, не объявленный модулем, а svn — позволяет. 3) в git нет прозрачной нумерации коммитов; что полезно для очень крупных проектов, раздражает на небольших.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #59

48. Сообщение от Аноним (-), 24-Дек-10, 17:57	–2 +/–
Человеческий мануал вместо "RTFSC" - уже ретроградство? Вы там со своим житом совсем уже с дуба рухнули?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

49. Сообщение от Crazy Alex (??), 24-Дек-10, 18:05	+1 +/–
git:// используется для анонимного доступа. Для "обновить qt" - в самый раз. Для auth есть git+ssh - всё есть и работает быстро. Если не хотите просаживаться на шифрование - выберите для ssh соответствующий легкий алгоритм шифрования (blowfish-cbc, например)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

50. Сообщение от Crazy Alex (??), 24-Дек-10, 18:11	+/–
Рабораю с ним больше  года. В самом начале били каике-то чудеса, но очень давно всё в порядке. Так что реплика как раз из серии "видел пару лет назад - не порадовало". А вот  поломанные рабочие копии при использовании Subversive видел не раз.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #55

51. Сообщение от Аноним (-), 24-Дек-10, 18:49	+1 +/–
Комменты доставляют. Сначала использовал svn, долго ненавидел git. Теперь же не понимаю, как можно использовать что-то ещё кроме git. И вот надо же, если бы я увидел это год назад, подумал что и правду git не стоит потраченных усилий. Как хорошо что год назад вас не было, дорогие анонимусы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #52

52. Сообщение от stomp (??), 24-Дек-10, 19:57	+/–
пользовался и svn, и git годами. второй годится разве что для kernel.org-подобных проектов, где все данные проходят через одного человека-тирана (он как раз и выполняет те функции централизации в DVCS, которые в централизованных VCS являются частью дизайна). для прозрачной слаженной командной работы svn подходит лучше
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #64

53. Сообщение от Аноним (-), 24-Дек-10, 20:23	–1 +/–
> Как Вы будете конфликты решать при push в рабочий каталог? По сети удалённо консоль Вам показывать? :) При push не возникает конфликтов, потому что рабочий каталог и репозиторий - разные вещи. У упоротых авторов гит видимо на всё своё мнение. > git работает с diff'ами, а не с файлами. У этой модели есть как минусы, так и плюсы. Для меня - плюсов больше, cp не нужен. Ну понятное дело, раз нету, значит не нужен.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #61

55. Сообщение от Аноним (-), 25-Дек-10, 10:11	+/–
Видел как раз около месяца назад. Оно не пригодно к использованию при http-доступе. Так что твоя реплика из серии "мне не нужно => никому не нужно".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #60

56. Сообщение от volax (?), 25-Дек-10, 12:37	+/–
http://code.google.com/p/bsd-sharp/downloads/list Там несколько методов заливки, но для портов используется portsnap
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29

57. Сообщение от Ytch (?), 25-Дек-10, 14:26	+/–
>bazaar вообще не рассматривается по причине маргинальности А вот это по-настоящему серьезный, сугубо технический и объективный аргумент! Надо бы этот параметр обязательно включать во все бенчмарки любых систем!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #75

58. Сообщение от Michael Shigorin (ok), 26-Дек-10, 00:57	+/–
Да ладно сказки-то рассказывать.  У нас git и так тоже используют -- средства для того самого быстрого мержа _несравнимы_ с cvs-ными.  И при этом локально ветки разводить не в пример удобнее. SVN со своим подходом хорош в локалке индусских кодеров, где можно хоть голосом синхронизироваться -- кто что коммитит.  Ну или с IRC в паре, и то уже больно начинает быть.  Да, он подходит для workflow, когда "а больше ничего и не требуется" -- беда в том, когда workflow уже не масштабируется, а его всё пытаются растягивать (вместе с инструментом). Да, git сложней и менее вылизан в плане въезда (и особенно переезда головой с CVS).  Но это более осмысленное вложение времени для программиста (для кодера, пожалуй, нет): для локальной работы осваивается за четверть часа, а с распределённой довольно важно заметить git-remote(1) и не страдать ручными fetch'ами в локальные бранчи. В любом случае хорошо, что инструментарий для централизованного воркфорва тоже пилят :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

59. Сообщение от Michael Shigorin (ok), 26-Дек-10, 01:04	+/–
> git не поддерживает: > 1) svn cp: сохранение истории при разделении файлов google://git+copy+history => http://markpasc.livejournal.com/186489.html?thread=556153#t5... > 2) svn import: git не позволяет импортировать кусок чужого проекта, не объявленный > модулем, а svn — позволяет. Хм, а зачем? (и ещё: git умеет обрабатывать ситуацию, когда один из подкаталогов сам является git repo -- возможно, это бы выручило) > 3) в git нет прозрачной нумерации коммитов; что полезно для очень крупных > проектов, раздражает на небольших. Какая может быть честная нумерация при распределёнке -- сколько ни думал, так и не придумал.  И заодно -- как с "прозрачной нумерацией", прибитой гвоздями, сделать что-нить вроде git rebase -i (ОСТОРОЖНО, оно острое!).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

60. Сообщение от Michael Shigorin (ok), 26-Дек-10, 01:07	–1 +/–
> Видел как раз около месяца назад. Оно не пригодно к использованию при > http-доступе. (сочувственно) Что, заставляют?  HTTP для git -- плохой транспорт, родной git или git+ssh работают куда веселей.  Хотя раз реализовано -- то, конечно, стоило бы для обиженных доступом поддержать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #55 Ответы: #65, #66

61. Сообщение от Michael Shigorin (ok), 26-Дек-10, 01:14	+/–
>> Как Вы будете конфликты решать при push в рабочий каталог? >> По сети удалённо консоль Вам показывать? :) > При push не возникает конфликтов, потому что рабочий каталог и репозиторий - > разные вещи. Вот только состояние верхушки той ветки репо (.git/), куда пушили, и чекаутнутой копии -- разъедется.  Что делать предлагаете? > У упоротых авторов гит видимо на всё своё мнение. По-моему, Вы просто пытаетесь ставить на место тех, чьи задачи и близко решать не возьмётесь.  Там выше про кодеров ещё писал. Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #70

62. Сообщение от Аноним (-), 26-Дек-10, 11:20	+/–
я не кодер... просто занимаюсь поддержкой(в плане сборки тестовых пакетов для Linux-base)... и могу сказать что Git менее удобен чем SVN.. даже в плане таких простых операций, как удаленный запрос номера ревизии и скачивание конкретно заданной ревизии(не говоря уж о том что в Git и понятия такого внятного нет, какой-то паранойдальный хеш)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #63

63. Сообщение от Michael Shigorin (ok), 26-Дек-10, 14:16	+/–
> я не кодер... просто занимаюсь поддержкой Ну так и не судите инструмент _разработчика_. :)  Я и пакеты собираю из гита, чем по большей части _уже_ доволен. > даже в плане таких простых операций, как удаленный запрос номера ревизии Поясните, какой ожидается результат запроса -- может, что соображу. > и скачивание конкретно заданной ревизии Если нужен снапшот -- обычно у проектов есть gitweb, а он даёт взять тарбол, соответствующий коммиту. (и историю там же может быть удобней глянуть краем глаза) >(не говоря уж о том что в Git и понятия такого внятного нет, >какой-то паранойдальный хеш) Ещё раз: он не "параноидальный", а отражает тот факт, что диффы и история изменений -- вещи необязательно связанные намертво. Например, есть у меня foo.c и bar.h; правлю foo.c и делаю один коммит; правлю их оба (foo.c в другом месте, т.е. правки не пересекаются) и делаю второй коммит. Внимание, вопрос: зачем какие-то искусственные ревизии, если может быть лучше (например, из соображений читабельности) перед публикацией эти коммиты поменять местами?  Изменения те же, результат -- тот же, а вот порядок изменился. (пресловутый git rebase --interactive и такое позволяет делать) Вообще рекомендую почитать при удобном случае вот эту статью: http://tomayko.com/writings/the-thing-about-git -- там разбирается как раз то, что git не вколачивает свой единственный правильный workflow в глотку пользователя ("и только мне попробуй шелохнуться!"), а предоставляет возможность наработать свой, удобный человеку. Да, это сложнее, как и любое творчество сложнее хождения строем.  И времени больше надо.  Но это не недостаток инструмента -- а либо про него Вам наврали, что "простой" (он не простой), либо есть желание уж лучше ходить строем (что дело личное).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #62 Ответы: #69

64. Сообщение от Michael Shigorin (ok), 26-Дек-10, 14:21	+/–
> пользовался и svn, и git годами. второй годится разве что для kernel.org-подобных > проектов, где все данные проходят через одного человека-тирана (он как раз > и выполняет те функции централизации в DVCS, которые в централизованных VCS > являются частью дизайна). для прозрачной слаженной командной работы svn подходит лучше Не так давно на глаза попадался более внятный разбор применимости -- с Вашим согласиться не могу, а там всё было толково разобрано.  Вчера сходу не нашёл опять. IMHO svn лучше подходит для слаженного кодирования разве что.  И притом _требует_ слаженности, планирования и возможности оперативного взаимодействия при внесении изменений.  Для кого-то такая внешняя дисциплина (как и питоний синтаксически значимый whitespace) -- нужна.  А для кого-то это неразумная и контрпродуктивная помеха, потому что человек опытней тех, на кого ориентировано такое менторство инструмента. Собсно не надо выдавать достоинства и недостатки _workflow_ за таковые _инструмента_.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

65. Сообщение от Аноним (-), 26-Дек-10, 16:20	+/–
Ну так пусть Лунис Торвальц и напишет в главном man: this project is a compilation of the worst ideas in DVCS  market. Those of them that were good are enforced to be bad by our design.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #67

66. Сообщение от Аноним (-), 26-Дек-10, 17:39	+/–
А впрочем, какая разница, что для гита (консольного) является плохим транспортом, когда на уровне гуя его никто не поддерживает толком: http://code.google.com/p/egit/issues/detail?id=57 И да: git+ssh требует наличия системного логина (как минимум pam должен знать о таком) для входа, что как ты понимаешь достойно места в списке киллер-фич жыта.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60

67. Сообщение от Michael Shigorin (ok), 26-Дек-10, 17:42	+/–
> Ну так пусть Лунис Торвальц и напишет в главном man: Давайте договоримся: я его об этом попрошу, когда удостоверюсь в Вашей личности и наличии в Вашем резюме фразы: "я неблагодарное лодырище, не только не осилил git, а полез плеваться на гораздо более компетентных в теме людей и вразумляться не собираюсь". Критиковать -- можно и нужно, да только вот с головой, а не языком ляпать. PS: хотя понятно, дальше egit Вам не дано и никакого конструктива Вы не ищете.  Удачи.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #71

68. Сообщение от Имя111223 (?), 27-Дек-10, 01:16	+/–
> При этом не задумываясь, что у vcs и dvcs достаточно разные задачи и масштабы, чтобы их объективно сравнивать. просто долго было писать фразу "для целей -- совместной разработки программы" .. думал что если уж написанно слово "программист" то и так ясно что реч идёт об программистской деятельности :-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

69. Сообщение от Имя111223 (?), 27-Дек-10, 01:27	+/–
> ...а либо про него Вам наврали, что "простой" (он не простой), либо ... "простой для изучения" и "простой для использования" -- это немного разные понятия инструмент зачастую бывает простой для использования -- но СЛОЖНЫЙ для изучения!! ---------- ..наглядный пример: КАРАНДАШ! карандошом легко писать слова (но это когда вы уже _научились_ правильно пользоваться карандошом).. ....но вспомните -- сколько требуется времени и усилий человеку чтобы овладеть навыком использования карандаша (для написания слов)!!! :-) времени явно больше чем время что требуется на изучение Git :-) :-) ---------- и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?" что вы ожидаете услышать? ответ на тему того что инстурмент простой для обучения? или что инструмент просто для повседневной работы?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #72

70. Сообщение от Аноним (-), 27-Дек-10, 03:54	+/–
> Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push. Алгоритм абсолютно такой же как при наличии отдельного bare репозитория, только без него. Это же и идиоту очевидно, только у любителей git видимо совсем чуждая нормальному человеку логика.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #73

71. Сообщение от Аноним (-), 27-Дек-10, 10:00	–1 +/–
А что, заставлять программеров пользоваться консолькой при каждом коммите/синхронизации/etc уже верх конструктива? Или есть всё же нормальные плагины к эклипсу? Если да, почему не гуглятся?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

72. Сообщение от Michael Shigorin (ok), 27-Дек-10, 13:19	–1 +/–
>> ...а либо про него Вам наврали, что "простой" (он не простой), либо ... > "простой для изучения" и "простой для использования" -- это немного разные понятия Разумеется.  Я считаю, что git достаточно сложен в изучении и бывает сложен в применении, но результат того _для меня_ стоит.  Но не для ламера, надо быть хотя бы честным чайником. > и вот когда вы спрашиваете кого-то "<такой-то> инструмент -- он простой?" Предпочитаю не задавать неоднозначных вопросов, чтоб не огорчаться ответами невпопад. :)  Вы прекрасно озвучили проблему с наивным стилем вопрошания.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

73. Сообщение от Michael Shigorin (ok), 27-Дек-10, 13:20	+/–
>> Если не слабо -- вперёд, обрисуйте разумный алгоритм обработки non-bare repo push. > Алгоритм абсолютно такой же как при наличии отдельного bare репозитория, > только без него. Это же и идиоту очевидно Ясно, слабо.  _Это_ действительно очевидно. PS: какой-такой "отдельный bare repo", задумайтесь хоть... и откуда "такой же", когда вместо одной сущности вдруг появляется две, причём речь именно о поддержании их взаимной синхронизации при совершении push.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #74

74. Сообщение от Аноним (-), 28-Дек-10, 19:52	+/–
Ты как всегда в своем троллеламерском стиле. при нормальном дизайне VCS working copy не прибит гвоздями к репозиторию, т.е. схема которую предлагают адепты недоразвитого git'а (push 1>bare, pull bare>2, rebase@2) работает без необходимости сторонних репозиториев (push 1>2, rebase@2). Элементарно, казалось бы. Но нет, мы пойдем другим путём.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #73 Ответы: #76

75. Сообщение от Аноним (-), 28-Дек-10, 19:56	+/–
> А вот это по-настоящему серьезный, сугубо технический и объективный аргумент! Вообще-то это нормальный аргумент. Причём объединяет в себе как причины, так и следствия убогости базара. Был бы хорошей VCS - был бы распространён чуть шире чем нигде это следствие. А причина - зачем ставить левоту когда везде есть и уже используются git/hg?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

76. Сообщение от Michael Shigorin (ok), 28-Дек-10, 20:41	+/–
> Ты как всегда в своем троллеламерском стиле. С зеркалом закончите разговаривать, сообщите. :) > при нормальном дизайне VCS working copy не прибит гвоздями к репозиторию, Озвучьте критерии "нормального дизайна VCS", пожалуйста.  Можно с примерами. > т.е. схема которую предлагают адепты недоразвитого git'а (push 1>bare, pull bare>2, > rebase@2) работает без необходимости сторонних репозиториев (push 1>2, rebase@2). *sigh* "1" и "2" -- это репозитории (так понимаю) или ветки?  Если первое, то какая проблема с fetch 2<1 или push в не-чекаутный бранч, если всё равно затем rebase? Пока похоже, что у Вас проблемы с pull vs push, а не чем-либо ещё.  И если так, то неудивительно. PS: судя по слогу и уровню аргументации, это опять подросток из оракла.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74

77. Сообщение от Аноним (77), 29-Мрт-20, 14:40	+/–
На дворе уже 2020, а svn всё ещё жив и процветает.
Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема