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

"Выпуск системы управления версиями Apache Subversion 1.14.0"	+/–
Сообщение от opennews (??), 28-Май-20, 23:16
Организация Apache Software Foundation опубликовала релиз системы управления версиями Subversion 1.14.0, который отнесён к выпускам с длительным сроком поддержки (LTS), обновления для которого будут выходить до 2024 года. Несмотря на развитие децентрализованных систем, Subversion продолжает пользоваться  популярностью в коммерческих компаниях и проектах, использующих централизованный подход к управлению версиями и конфигурацией программных систем. Из  использующих Subversion  открытых проектов можно отметить: проекты Apache, FreeBSD, Free Pascal и OpenSCADA. Отмечается, что в едином рSVN-епоизитории проектов Apache хранится около 1.8 миллионов ревизий с информацией об изменениях в проектах... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=53047
Ответить | Правка | Cообщить модератору

Сообщения

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

1. Сообщение от Аноним (1), 28-Май-20, 23:16	+/–
А где-нибудь можно почитать о том, почему пользователи Subversion выбирают именно его? Чем таким оно лучше того же Git'а?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #6, #9, #13, #48

2. Сообщение от Аноним (4), 28-Май-20, 23:20	–4 +/–
Только не говорите что устарело, может в вашем open source git победил, но в работе с мультимедией и тяжелыми исходниками в серьёзных корпорациях ваш гит будет сливать в чистую. Там где надо загрузить одну картинку размером 900 Кб придётся клонировать весь репозиторий терабайт на 5
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #12, #14, #21

4. Сообщение от Аноним (4), 28-Май-20, 23:27	–4 +/–
Попробуйте хранить в гите .blend файлы, он моментально раздуется. А svn будет хорошо, конечно на сервере будет раздуваться, но не на каждом клиенте. То же фонд блендера свои мультфильмы в svn хостили
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #5, #7, #22, #93

5. Сообщение от Аноним (1), 28-Май-20, 23:32	–1 +/–
В гите совсем нет возможности подрезать хранимый объём старых комитов? Я честно не знаю. Я дальше пары команд из мануала не практиковал его ещё.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #47

6. Сообщение от Аноним (6), 28-Май-20, 23:34	–1 +/–
А нужен ли гит, если его используемые фичи перекрываются svn с запасом? Смотришь на том же гитхабе - один проект, один автор и одна ветка. Смахивание на попытку вскопать огород вскрышным экскаватором.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #11, #15, #20, #53, #56, #94

7. Сообщение от erthink (ok), 28-Май-20, 23:46	+2 +/–
В git всё давно есть, только больше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

8. Сообщение от gitover (?), 28-Май-20, 23:47	+4 +/–
git lfs? нет - не стлышал...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10

9. Сообщение от Аноним (9), 28-Май-20, 23:51	+6 +/–
Права доступа на директорию, получение любого файла без клонирования, обновление части проекта, блокировка файлов, externals
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

10. Сообщение от Аноним (24), 28-Май-20, 23:57	–2 +/–
Костыль
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #17

11. Сообщение от Аноним (24), 29-Май-20, 00:00	+/–
Кстати, гитхаб поддерживает работу с svn-клиентами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #36

12. Сообщение от no country for old men (?), 29-Май-20, 00:07	+/–
Чукча не читатель, чукча -- писатель. https://git-lfs.github.com/
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

13. Сообщение от erthink (ok), 29-Май-20, 00:20	+2 +/–
1. Гитом достаточно сложно пользоваться не понимая как он работает. Поэтому основная причина = нежелание изучать новое и/или менять привычное. Адепты svn нередко говорят что в git нет "externals" (на самом деле есть submodules и subtree), нет возможности обновить часть проекта (на самом деле checkout умеет). 2. Идеологическая разница. В svn есть центральный репозиторий/сервер, а git предлагает каждой копии быть самодостаточной. Поэтому в svn есть набор странных "фиче-костылей": - права доступа на директорию, в git это абсурдно (но при желании можете локально выполнить chmod/chown). - блокировка файлов "на сервере", в git вы хозяин локальной копии, а "на сервере" может жить множество версий без проблем. - и т.д. образно говоря, в git нет кучи проблем, поэтому нет средств для их преодоления. И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных участников. 3. Иногда добавляется еще одна причина - нежелание менять кучу скриптов. 4. Иногда примешивается "религия" - freebsd не может перейти на git...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #16, #19, #23, #31

14. Сообщение от хотел спросить (?), 29-Май-20, 00:34	–2 +/–
можно вытащить с веб морды.. например в GitLab
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #18

15. Сообщение от имя (ok), 29-Май-20, 01:15	+1 +/–
> А нужен ли гит, если его используемые фичи перекрываются svn с запасом? Смотришь на том же гитхабе - один проект, один автор и одна ветка. Смотришь на том же sourceforge на пользователей svn, а там всё то же самое. Тем временем у продвинутой аудитории вместо срачей «merge или rebase» сплошные форумные треды о том, как же правильно пользоваться ветками — это, по-вашему, «перекрытие с запасом»? А васяны, пишущие в стол и никуда не собирающиеся в данный момент публиковать код, чертыхаясь, пытаются поднять svnserve, не осиливают или решают, что для их поделки это слишком дофига телодвижений, и возвращаются к разведению «новых папок (2)».
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #37

16. Сообщение от Gemorroj (ok), 29-Май-20, 01:44	–7 +/–
по факту у гита 1 преимущество - мода (распространенность). децнтрализованность нафиг не вперлась. а вообще ты странный человек. svn чист и понятен, и это его преимущество. в гите куча всякой лабуды. ты же зачем-то пытаешься черное назвать белым и наоборот.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

17. Сообщение от Аноним (17), 29-Май-20, 02:36	+/–
Да, ну и что?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

18. Сообщение от DiabloPC (ok), 29-Май-20, 03:10	–1 +/–
Ага, а потом непонятно каким образом затолкать её в локальное дерево. Ню-ню
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #14 Ответы: #44

19. Сообщение от Ivan_83 (ok), 29-Май-20, 03:57	+/–
Фря таки туда упорно идёт. Даже какой то коммитет вроде есть, и живые зеркала на гитхабе.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #27

20. Сообщение от Аноним (20), 29-Май-20, 04:24	+3 +/–
Ты юродивый или прикидываешься? На дядю работал когда-нибудь разрабом? Как еще нормально девелопить, когда вас на проекте десяток и всем нужно вливать результат своего труда в "общее дело" без какой-либо боли в голове и жопе на ровном месте? Только механика бранчевания и спасает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #38, #42, #54

21. Сообщение от Аноним (20), 29-Май-20, 04:25	+/–
Дядь, почитай про sparse checkout.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #57

22. Сообщение от Аноним (22), 29-Май-20, 06:44	+3 +/–
>Попробуйте хранить в гите .blend файлы Двойное нeнужнo. Прекрасно храним .ma, .mb, .hip фанеры и файлы в perforce и он не раздувается. 👍
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #24

23. Сообщение от Ю.Т. (?), 29-Май-20, 07:58	–1 +/–
В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл". А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?..
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #25, #46

24. Сообщение от Аноним (24), 29-Май-20, 08:05	–3 +/–
Он же проприетарный
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22 Ответы: #29

25. Сообщение от Аноним (64), 29-Май-20, 08:46	+1 +/–
> Сделал человек патч, а гит не знает Странный у тебя гит, мой умеет. git apply m.patch
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

26. Сообщение от КО (?), 29-Май-20, 09:21	+/–
>не прибегая к таким ухищрениям как сохранение патча через "svn diff" с последующим его восстановлением через "svn patch". А я то просто еще одну папку с транком делал и в ней уже правил. Но, наверное, это слишком сложно. :)
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #39

27. Сообщение от пох. (?), 29-Май-20, 09:51	–5 +/–
> Фря таки туда упорно идёт. ну так туда уже давно набилось полно вчерародившихся, неспособных освоить ничего, кроме жмаканья кнопочек на гитшлаке. Так что фря упорно идет в ту же мусорку что и линукс и по тем же причинам. Причем - опережающими темпами, ибо продукт соракатысяч обезьян вполне достаточен и один.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19

28. Сообщение от ALex_hha (ok), 29-Май-20, 09:53	–2 +/–
> И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных участников. Это не ограничения, а особенности svn. А то с таким же успехом можно сказать, что у машины два ограничения - она не умеет летать и плавать :D
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

29. Сообщение от Аноним (29), 29-Май-20, 10:00	+1 +/–
А что плохого?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #49

30. Сообщение от ALex_hha (ok), 29-Май-20, 10:07	+1 +/–
> Дядь, почитай про sparse checkout Слышал звон ... чтобы его настроить ты сначала должен клонировать всю репу ;) "Sparse checkout" allows populating the working directory sparsely. It uses the skip-worktree bit (see git-update-index[1]) to tell Git whether a file in the working directory is worth looking at. If the skip-worktree bit is set, then the file is ignored in the working directory. Git will not populate the contents of those files, which makes a sparse checkout helpful when working in a repository with many files, but only a few are important to the current user.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #34, #87

31. Сообщение от пох. (?), 29-Май-20, 10:14	–2 +/–
> 1. Гитом достаточно сложно пользоваться - потому что он by design - дерьмо поправил, не благодари. Чтобы пользоваться электропилой - не нужно понимать как работают асинхронные электродвигатели - совсем. Нужно уметь ей пилить, не оттяпав себе ногу и не уронив дерево на голову. Поэтому она таки лучше бензиновой, где волей-неволей придется приобретать совершенно ненужные навыки моториста. git устроен настолько уродливо и нефункционально (потому что его изначальная функция перпендикулярна человеческим vcs - сбор патчей из мусора рассылки) - что без знания его совершенно уродских и бесполезных потрохов им действительно сложно делать что-то сложное. К счастью великому макак-разработчиков - им это и не нужно. Они умеют кодить, а не пользоваться vcs. git clone, git commit, git push. Что эти команды означают - знать незачем. Самые крутые знают про rebase. Впрочем, visual studio или phpstorm все это делает за них, от альтернативно-одаренного требуется только указать репо на гитшлаке. svn придумана совершенно для иной цели - совместной работы с кодом, БЕЗ костыликов и подпорочек в виде веб-морды на пол-терабайта оперативы. > Идеологическая разница. В svn есть центральный репозиторий/сервер, а git предлагает каждой > копии быть самодостаточной в разработке одного проекта нет и не может быть никаких "самодостаточных". Их по факту и нет. "самодостаточность" твоей копии кончается на первом же push. > права доступа на директорию, в git это абсурдно действительно, с точки зрения макаки это абсурдно, какие еще права доступа, она и слов таких не знает. Чмод какой-то нашла в гугле, хз что означает - говорят, самый крутой - 777, о, заработало. Что кто-то может дать тебе возможность изменять _только_ доверенную тебе часть репо, и это не имеет ни малейшей связи с локальными атрибутами файлов на твоем макбучеке - тебе и в голову не придет, да? И да, у svn нет никакой катастрофы хранить закрытые ключи и прочие нужные для запуска артефакты, которых так боятся случайно подгрести в комит гитляпцы - ты их даже и не увидишь. > блокировка файлов "на сервере", мы уже поняли что вы не умеете пользоваться svn > в git вы хозяин локальной копии которой можете подтереться, если, конечно, все еще собираетесь совместно работать. По факту вы не хозяин в ней даже своим изменениям - "ваша история нахрен нам не вперлась, нас интересует только наша история" - rebase или format-patch. И да, не забудьте порезать поменьше, в экран не влазиет. > И этого следует принципиальное ограничение - svn плохо масштабируется по кол-ву активных > участников. svn прекрасно поддерживает громадные проекты. Видимо, проблема не в том что плохо масштабируется, а в том что вы ничего кроме порежьте-помельче-пришлите не умеете?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13

34. Сообщение от Аноним (64), 29-Май-20, 10:21	+/–
Акелла то промахнулся.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30

35. Сообщение от пох. (?), 29-Май-20, 10:27	–1 +/–
это вообще не имеет ни малейшего отношения к svn. Только к дисциплине разработки. Если у вас кто угодно может что угодно запушить в remote/master - не вижу чем это будет отличаться в лучшую сторону от работы с svn. Кто первым успел, того будут тапки, кто нет - делает новый rebase и снова пытается успеть пока туда не закомитили что-то еще - а то снова rebase и снова успеть-успеть. Только вот в svn никто не мешает любому количеству _доверенных_ людей работать в разных частях репо (а система прав доступа - не позволит случайно наломать дров) - и им не придется стоять в очереди на push. Если у вас вообще ничего пушить нельзя, потому что запрещено, а есть система code review - совершенно все равно, svn там или что. Вы вынуждены работать с патчами по отдельности через интуитивно-приятный веб-интерфейс (нет, хотите - читайте их в рассылке, только я не знаю, как вы этот делаете и чем).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

36. Сообщение от пох. (?), 29-Май-20, 10:32	–1 +/–
это не github, а git-svn поддерживает. Причем делает это так, что лучше бы не поддерживал - может кто нормальное бы что написал (только вряд ли) Ты видел, во что оно превращает историю и логи на обоих концах цепочки?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11 Ответы: #62

37. Сообщение от пох. (?), 29-Май-20, 10:40	–1 +/–
> А васяны, пишущие в стол и никуда не собирающиеся в данный момент публиковать код, чертыхаясь, > пытаются поднять svnserve, не осиливают и, надеюсь, идут в макдак продавцами? Потому что что нагуанокодит ниасилятор поднять svnserve для самого себя - я боюсь даже представить. Кстати, не хотел бы тебя огорчать, но для кода, который ты не собираешься публиковать, svnserve не нужен, это средство публикации. В отличие от гита - самодостаточное, обеспечивающее разделение прав доступа и fine-grained контроль. > сплошные форумные треды о том, как же правильно пользоваться ветками я так и не сумел научить наших разработчиков пользоваться ветками - вообще. Они в принципе не понимают, для чего нужны ветки. Разные варианты одного и того же кода - раскладывают именно в новаяпапка(28), хотя они не то что никогда не бывают нужны на одном сервере, а опасны - возможностью случайно запустить не тот. В гите, да. Зато каждая отдельная задача (по полсотни в день!) оформляется в виде ненужной ветки и ненужного мержа в мастер.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15 Ответы: #58

38. Сообщение от Линус (?), 29-Май-20, 10:43	+2 +/–
> всем нужно вливать результат своего труда в "общее дело" порежьте помельче, у меня в экран не влазиет, каждый патч заверните, пришлите в рассылку. > без какой-либо боли в голове и жопе а у меня ничего и не болит!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

39. Сообщение от пох. (?), 29-Май-20, 10:49	–1 +/–
Это сложно, если бы ты правил не одну строчку, потому что ты теперь не можешь результат своих правок вмержить в предыдущую - ты можешь только закомитить их в репо, если тебе это разрешено, или вручную (потому что нет локальных комитов) собирать патчи поштучно. Старайся ничего не забыть и не перепутать. А еще есть места где используется svn, но файлики могут лежать только в одном-единственном специальном месте. Потому что в других они не будут работать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

42. Сообщение от Аноним (42), 29-Май-20, 12:13	–1 +/–
Не шуми, мальчик. Сходи к взрослым дядям, например, сюда https://codereview.qt-project.org и посмотри, на каком суку они крутили твоё брэнчевание. И твои коммиты им тоже нафиг не нужны. Их надо в один преобразовывать. А потом ещё посмотри на тему линейности истории.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20 Ответы: #45

44. Сообщение от пох. (?), 29-Май-20, 12:21	+/–
git am/git patch жеж. Эти [censored] НА САМОМ деле вот так, через задницу все делают. И считают что так очень удобно - передние лапы освобождаются для дро4ки.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #18 Ответы: #76

45. Сообщение от пох. (?), 29-Май-20, 12:29	–1 +/–
> Сходи к взрослым дядям а вот это точно взрослые? > И твои коммиты им тоже нафиг не нужны. действительно. Им вообще никто не нужен. > Их надо в один преобразовывать. чтобы уже точно никто не смог разобраться, что ты там делал, а главное - зачем и почему. Ну и правильно. И незачем. Это впопенсорс в руках корпорации. Перевод чужого времени в помойку. > А потом ещё посмотри на тему линейности истории. зачем вам вообще какая-то история? Вы все равно не знаете что с ней делать. Версия у вас может быть только самая распоследняя. Остальное немодно и немолодежно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #60

46. Сообщение от пох. (?), 29-Май-20, 12:41	+1 +/–
> В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл". вы похоже ниасилили гит даже на уровне терминологии? pull может сделать только владелец репо. Ты мог бы сделать только push, но чужое репо тебе обычно недоступно на запись. В наше время при нынешних размерах того ПО - очень неудобно работать с присылаемыми порезанными помельче патчами. Поэтому вполне разумно как раз делать pull-request (для неосиляторов: это _просьба_ владельцу сделать pull from me), в терминах гитшлака. Альтернативный метод - технологии code review. Когда патчи не валят кучей в рассылку, а скармливают какой-нибудь вебморде. На предмет смотрения глазками. commit или push в зависимости от технологии - сделает вебморда, от имени и по поручению того у кого есть право одобрять изменения. Что не мешает доверенным разработчикам - работать в обход, напрямую с репо. > А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?.. и патч скорее всего - тоже г-но, он ведь такой еще много чего не знает. Как программировать уж точно не. Так что если уж ниасилено даже нажать кнопочку clone me on github (гит для этого, кстати, знать незачем) - ну его нахрен тратить время разработчиков на такого альтернативно-одаренного.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23 Ответы: #50

47. Сообщение от пох. (?), 29-Май-20, 13:18	–1 +/–
причем тут "старые комиты"? blend файлы вряд ли часто обновляют - хватит ровно одной копии. Просто потому что она огромная. В случае svn ты можешь просто не чекаутить ненужные тебе гигасы филеза. В случае git ты их тоже можешь не чекаутить - но легче тебе от этого не станет, поскольку они у тебя будут в .git в твоей локальной копии. Существуют ли в природе dvcs, умеющие работать только с частью дерева - учоные спорят. Но microsoft уже бежит к вам на помочь, со своей lfs.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #55

48. Сообщение от anonymous yet another (?), 29-Май-20, 13:19	–2 +/–
Вопрос не корректный. subversion старше, а не лучше.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #51

49. Сообщение от пох. (?), 29-Май-20, 13:22	–1 +/–
манагер денег не дает - "вот же, тут 6ешплатно. взять, взять!" Лучше б рассказал кто в курсе - что, почем, где там грабли раскиданы. А то куды бежать с hg - я вот не знаю. svn не очень подходит для параллельной работы, увы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #61, #64

50. Сообщение от Ю.Т. (?), 29-Май-20, 13:26	–2 +/–
>> В наше время свободное-ПО-сообщество вместо "присылки патчей" навязывает "сделай мне пулл". > вы похоже ниасилили гит даже на уровне терминологии? > pull может сделать только владелец репо. Ты мог бы сделать только push, А мужики-то и не знали. Я передал ЖАРГОН разработчиков, затычка ты в каждую бочку. >> А это поднимает порог вхождения. Сделал человек патч, а гит не знает, не профешнл разраб. И?.. > и патч скорее всего - тоже г-но, он ведь такой еще много > чего не знает. Как программировать уж точно не. Один ты всё на свете знаешь. "Одна только горесть -- никто не читает".
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #52

51. Сообщение от пох. (?), 29-Май-20, 13:27	–1 +/–
два года разницы в двадцатилетнем проекте имеют очень больше значение. (нет) subversion отпочковался от cvs в 2000м, bitkeeper который кое-как скосплеили в git - всучили линусу в 2002м.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #48 Ответы: #63

52. Сообщение от пох. (?), 29-Май-20, 13:33	+1 +/–
> А мужики-то и не знали. Я передал ЖАРГОН разработчиков Скорее - единственного горе-разработчика - себя. Я вот ни от каких разработчиков подобного бреда не слышал - вероятно, они все же умеют кое-как отличать одно от другого и не путаться. И себя же описал в "а гит не знает". > "Одна только горесть -- никто не читает". опять мимо. Никто не читает твои сверхценные патчи, которые ты не умеешь правильно подать - это да. Порог вхождения, все такое. Ниасилил? Попробуй обратись в debian - там любят умственно-отсталых.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #59

53. Сообщение от Аноним (54), 29-Май-20, 13:36	+/–
А если появится 2-3 автора? Сразу будет много веток
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #69

54. Сообщение от Аноним (54), 29-Май-20, 13:37	+/–
У нас на работе всего 3 программиста, но без веток вообще ничего сделать невозможно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

55. Сообщение от user (??), 29-Май-20, 13:46	+/–
Ещё одна причина не использовать монорепо. Кто сам не редактирует это блобы, тот должен их обновлять через пакетный менеджер или rsync.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47

56. Сообщение от Аноним (54), 29-Май-20, 13:49	+/–
>А нужен ли гит, Мне ветки git понадобились даже когда просто по книжке занималась, git это не экскаватор.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #96

57. Сообщение от Аноним (75), 29-Май-20, 13:50	+/–
> git-sparse-checkout - Initialize and modify the sparse-checkout configuration, which reduces the checkout to a set of paths given by a list of patterns. По моему это про checkout, а не про clone, нет? > THIS COMMAND IS EXPERIMENTAL. ITS BEHAVIOR, AND THE BEHAVIOR OF OTHER COMMANDS IN THE PRESENCE OF SPARSE-CHECKOUTS, WILL LIKELY CHANGE IN THE FUTURE. Не внушает доверия.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

58. Сообщение от user (??), 29-Май-20, 13:50	+/–
Гит на сервере - ССЗБ. Неосиляторы rsync должны страдать.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37 Ответы: #67

59. Сообщение от Ю.Т. (?), 29-Май-20, 14:03	–1 +/–
Компенсируем что-то, да никак не выкомпенсируем. > Порог вхождения, все такое. Ниасилил? Попробуй обратись в debian - там любят > умственно-отсталых. Ну я тебе уклончиво ответил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

60. Сообщение от anonymous yet another (?), 29-Май-20, 14:19	+1 +/–
> зачем вам вообще какая-то история? Вы все равно не знаете что с ней делать. > Версия у вас может быть только самая распоследняя. Остальное немодно и немолодежно. Всё верно. А распоследняя версия оказалась заброшенной в полуразобранном состоянии лет пять назад, когда основной и единственный разработчик решил продолжить саморазвитие в другой компании.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45 Ответы: #68

61. Сообщение от anonymous yet another (?), 29-Май-20, 14:29	+/–
> А то куды бежать с hg - я вот не знаю. svn > не очень подходит для параллельной работы, увы. Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются). Если мартышкам в руки давать --- купите что-то вроде smartgit --- там кнопки есть, можно давить. И обложите ограничениями прав на серверной стороне (под gitlab или bitbucket, ...), чтобы не порушили чего по природной сообразительности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #66

62. Сообщение от anonymous yet another (?), 29-Май-20, 14:35	+/–
> это не github, а git-svn поддерживает. > Причем делает это так, что лучше бы не поддерживал - может кто > нормальное бы что написал (только вряд ли) > Ты видел, во что оно превращает историю и логи на обоих концах > цепочки? Это руки из ... . Можно и аккуратно делать. И чинить эпичекие концептуальные мегаумствования аторов subversion (это каждый раз уникально; я думал, я всё уже видал, но они там всё равно находят свежие назамутнённые мыслью приёмы).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36

63. Сообщение от anonymous yet another (?), 29-Май-20, 14:51	+/–
> subversion отпочковался от cvs в 2000м, bitkeeper который кое-как скосплеили в git > - всучили линусу в 2002м. И первое не верно и второе тоже.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

64. Сообщение от Аноним (64), 29-Май-20, 16:13	–1 +/–
hg был хорош, особенно в плане мержей и конфликтов, жаль git победил.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #49 Ответы: #65

65. Сообщение от пох. (?), 29-Май-20, 16:36	+/–
> hg был хорош, особенно в плане мержей и конфликтов, жаль git победил. там обратная беда была - иногда таки и впрямь ненужно тащить свою внутреннюю кухню в чужой проект, а надо выдать пачку патчей поверх состояния - чужого, которое тебе нафиг не нужно. Отражающих структуру кода (не "порежьте помельче", а структуру ;-) а не историю твоей возни с ним - потому что дальше возиться будет кто-то другой. Это сделали через mq, и так что лучше б не делали - опять нужны ненужные знания о внутреннем устройстве инструмента. hg был хорош пока у тебя вся разработка общая, либо ты пилишь в одно жало параллельно несколько веток (в svn мержи такие что после второй ветки проще удавиться чем за ними уследить, и именно эту проблему hg решил раз навсегда, у него любой комит это мерж) К сожалению, по всей видимости, svn его успеет пережить. Именно за счет авторизации, разделения доступов и возможности не таскать за собой потроха репо там, где нужен только чекаут или вообще одноразовый export. А "распределенность" сама по себе оказалась не так полезна, как о ней рассказывали.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #85

66. Сообщение от пох. (?), 29-Май-20, 16:50	–2 +/–
>> А то куды бежать с hg - я вот не знаю. svn >> не очень подходит для параллельной работы, увы. > Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются). мне для себя, не для мартышек. Есть вещи которые делаются в нескольких параллельных ветках. Ветки эпизодически (кусками) мержатся, причем - в любую сторону. svn такого не любит, в нем мерж допустим только из trunk вниз. git чудовищно неудобен - во всем (hg местами, к этому можно было привыкнуть). Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? Как минимум, попытка сохранить фиксацию версий говорит о том что люди делали это для себя. > Если мартышкам в руки давать --- купите что-то вроде smartgit --- там > кнопки есть, можно давить. И обложите ограничениями прав на серверной и кто мержить за них будет - я? Нафиг-нафиг-нафиг. за них гуи думают. Я поразился, поставив себе msvc, насколько вообще можно ничего не понимать в том как оно работает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #70

67. Сообщение от пох. (?), 29-Май-20, 16:53	–1 +/–
> Гит на сервере - ССЗБ. Неосиляторы rsync должны страдать. а история ненужна, ага.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #58 Ответы: #79

68. Сообщение от пох. (?), 29-Май-20, 16:54	–1 +/–
> Всё верно. А распоследняя версия оказалась заброшенной в полуразобранном > состоянии лет пять назад, когда основной и единственный разработчик > решил продолжить саморазвитие в другой компании. я тут наблюдаю картинку "иногда они возвращаются". Вам казалось, что п-ц уже давно настал? Нет, вам казалось! ;-)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #72

69. Сообщение от пох. (?), 29-Май-20, 17:06	+1 +/–
> А если появится 2-3 автора? Сразу будет много веток они у вас что - один и тот же файл переписывают? Проект настолько спагетти-кодом, что трогает один, а в тарелке что-то начинает шевелиться у другого? Бегите оттуда! Постоянное создание веток - это багофича (by design) гита, работающие в транке рано или поздно нечаянно делают pull поверх своего наработанного, и потом прибегают ко мне с воплями "как провернуть фарш назад?" Это при условии что им хотя бы forced push недоступен. А то бегать можно уже кругами только будет. В svn ветки создаются только когда нужно параллельно поддерживать разные версии проекта. Параллельно работать над разными частями можно без всяких веток, он именно на такой режим и заточен. Сломать всем репо или сломать себе - ты не сможешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #53 Ответы: #73

70. Сообщение от anonymous yet another (?), 29-Май-20, 17:56	+1 +/–
>[оверквотинг удален] >> Вообще-то git сильно мощнее hg будет (а концептуально они довольно сильно пересекаются). > мне для себя, не для мартышек. Есть вещи которые делаются в нескольких > параллельных ветках. Ветки эпизодически (кусками) мержатся, причем - в любую сторону. > svn такого не любит, в нем мерж допустим только из trunk > вниз. > git чудовищно неудобен - во всем (hg местами, к этому можно было > привыкнуть). > Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? > Как минимум, попытка сохранить фиксацию версий говорит о том что люди > делали это для себя. Видите ли, если для себя, то сильнее git'а ничего нет. Надо идти и разбираться. Там почти всё по делу. Идеи, лежащие в основе --- гениальны (т.е. они пригодились и позволили делать вещи, о которых изначально и не предполагали, не трогая концепцию). P4 для разработки --- сплошное мучение. Его концептуально, похоже, делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ специфичными хотелками. Всякая прочая деятельность на нём --- хождение по мукам. Если, конечно, вам не нужен большой файлообменник с версионированием файлов (правда сильно большие файлы нельзя, и зараз пихать много файлов тоже нельзя). Т.е. пользоваться можно, но за очень большие деньги. Пользователю. За вредность. Конторка, которая его делает --- чует конец и переобувается в консультантов и создателей цветастых окошек поверх git'а.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #71, #74

71. Сообщение от Няшмяш (?), 29-Май-20, 18:11	+1 +/–
>[оверквотинг удален] > P4 для разработки --- сплошное мучение. Его концептуально, похоже, > делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ > специфичными хотелками. Всякая прочая деятельность на нём --- > хождение по мукам. Если, конечно, вам не нужен большой файлообменник > с версионированием файлов (правда сильно большие файлы нельзя, > и зараз пихать много файлов тоже нельзя). > Т.е. пользоваться можно, но за очень большие деньги. > Пользователю. За вредность. > Конторка, которая его делает --- чует конец и переобувается в консультантов > и создателей цветастых окошек поверх git'а. Очень хорошо сказано.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #90

72. Сообщение от anonymous yet another (?), 29-Май-20, 18:14	+1 +/–
> я тут наблюдаю картинку "иногда они возвращаются". Вам казалось, что п-ц уже > давно настал? Нет, вам казалось! ;-) - А что делать? - Плюнь в рожу вождю! ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #68

73. Сообщение от anonymous yet another (?), 29-Май-20, 18:16	+/–
> В svn ветки создаются только когда нужно параллельно поддерживать разные версии проекта. > Параллельно работать над разными частями можно без всяких веток, он именно > на такой режим и заточен. Сломать всем репо или сломать себе > - ты не сможешь. Сможешь. Умеючи --- не долго.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #69

74. Сообщение от пох. (?), 29-Май-20, 18:31	–1 +/–
>> Вот и спрашиваю - что там с пефорсой, может ей можно пользоваться? >> Как минимум, попытка сохранить фиксацию версий говорит о том что люди >> делали это для себя. > Видите ли, если для себя, то сильнее git'а ничего нет. > Надо идти и разбираться. Там почти всё по делу. Идеи, лежащие в но мне не нужно уметь извлекать патчи из рассылки. И отправлять их обратно, что характерно - тоже, я комичу в транк, да. (мне нужна _моя_ история) А обычная моя работа в нем чудовищно неудобна. Я не хочу думать о кишках двигателя - я хочу просто пользоваться удобным инструментом - и мне совершенно все равно какая там магия под капотом. Например, без персистентных человекочитаемых версий - чудовищно неудобно. Это как раз и говорит о том, что изобретателям гитоподелки история вообще нах не вперлась, возвращаться к ней они не планируют. > P4 для разработки --- сплошное мучение. Его концептуально, похоже, можно все же - детали, а не мнения? > делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ > специфичными хотелками. Всякая прочая деятельность на нём --- вдруг мои хотелки - совпадут. > хождение по мукам. Если, конечно, вам не нужен большой файлообменник > с версионированием файлов (правда сильно большие файлы нельзя, НУЖЕН! > и зараз пихать много файлов тоже нельзя). сколько в граммах? "Большие" и "много" у всех свои. > Конторка, которая его делает --- чует конец и переобувается в консультантов > и создателей цветастых окошек поверх git'а. останется только один, причем, как обычно, наихудший. Но я не собираюсь жить вечно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70 Ответы: #75, #82

75. Сообщение от Аноним (75), 29-Май-20, 19:34	–1 +/–
> Например, без персистентных человекочитаемых версий - чудовищно неудобно Имена у branch и tag — человекочитаемы, а персистентность можно обеспечить административными способами
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #80

76. Сообщение от Anonymoustus (ok), 29-Май-20, 19:43	+3 +/–
Для завивки шерсти на хвосте. Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML? Напиши книжку советов. На опеннете всё равно потеряется, а так бы кто-то читал и просвещался.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44 Ответы: #77, #81

77. Сообщение от Няшмяш (?), 29-Май-20, 19:51	+1 +/–
> Для завивки шерсти на хвосте. > Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML? > Напиши книжку советов. На опеннете всё равно потеряется, а так бы > кто-то читал и просвещался. Во истину, все проблемы человечество от отсутствия сей великой книги!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76 Ответы: #78

78. Сообщение от Anonymoustus (ok), 29-Май-20, 20:18	–1 +/–
>> Для завивки шерсти на хвосте. >> Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML? >> Напиши книжку советов. На опеннете всё равно потеряется, а так бы >> кто-то читал и просвещался. > Во истину, все проблемы человечество от отсутствия сей великой книги! Кому как, а я регулярно читаю здесь в исполнении Поха разные неожиданные мысли и решения.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77

79. Сообщение от user (??), 29-Май-20, 21:10	–1 +/–
Разрабатывать прямо на проде? Мсье знает толк в адреналине и вазелине.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #67

80. Сообщение от пох. (?), 29-Май-20, 22:14	+/–
Меня не интересуют ваши любимые привычные костыли и обязательность ношения намордника под угрозой штрафа, а так же как через него вы умудряетесь жрать г-но с лопаты. Меня интересует для себя, любимого, сделать - хорошо и удобно. Можно за деньги. И никогда-никогда не видеть убе...ских номеров комитов. Это изобрести мог только один человек - тот, которому нахрен не нужна история, и, соответственно, vcs вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #75 Ответы: #91

81. Сообщение от пох. (?), 29-Май-20, 22:40	+/–
> Пох, а LaTeX ты знаешь? Или, на худой конец, DocBook или HTML? > Напиши книжку советов. На опеннете всё равно потеряется, а так бы я из принципа написал бы на *roff, пусть-ка потрахаются прочитать. (интересно, порешали там проблемы с locale, за 20 лет, или снова самому патчить?) Для заметок углем на манжетах вполне подходящий инструмент. Но скорее я потрачу оставшиеся годы жизни на книжку по психологии приручения собак (человечьей, конечно). От храпящего на ковре пушистого "коврика", радости как-то больше, чем от ущербных технологий.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #76

82. Сообщение от anonymous yet another (?), 30-Май-20, 00:14	+/–
> но мне не нужно уметь извлекать патчи из рассылки. И отправлять их > обратно, что характерно - тоже, я комичу в транк, да. (мне > нужна _моя_ история) Это что, легенда какая-то или психологическая травма? Есть ситуации когда так удобно. Иногда очень удобно. Но это далеко не единственный workflow. > А обычная моя работа в нем чудовищно неудобна. Я не хочу думать > о кишках двигателя - я хочу просто пользоваться удобным инструментом - > и мне совершенно все равно какая там магия под капотом. Например, > без персистентных человекочитаемых версий - чудовищно неудобно. Это как раз и > говорит о том, что изобретателям гитоподелки история вообще нах не вперлась, > возвращаться к ней они не планируют. Persistent human-readable --- зто про r100500? Так ни в одном из вменяемых DVCS'ов так не делают по вполне понятным причинам. Да и централизованных системах цена этого решения сильно высока. А смысла нет. (мало-мальски нетривиальное версионирование --- это слабоупорядоченные множества, и смысл этой человеко-читаемости идёт мимо). >> P4 для разработки --- сплошное мучение. Его концептуально, похоже, > можно все же - детали, а не мнения? Да берите и пробуйте. По мне --- очень дорогое г. (акцент на "г.", а не на "дорогое"). >> делали для каких-то пары-тройки очень жирных клиентов с ООООЧЕНЬ >> специфичными хотелками. Всякая прочая деятельность на нём --- > вдруг мои хотелки - совпадут. Вам виднее. На вкус и цвет, как известно, все фломастеры разные. >> хождение по мукам. Если, конечно, вам не нужен большой файлообменник >> с версионированием файлов (правда сильно большие файлы нельзя, > НУЖЕН! Так флаг вам в руки, барабан на шею и ветер в спину. В одном кооперативе (он там и как VCS заодно используется ;)) по факту через P4 презентациями и аналогами докладных записок (а заодно фотографиями, мувиками, ...) обмениваются. Каждые два-три месяца на регламент ложился --- полки, наверное, доставляли. Ну, и ценность истории при такой организации работы --- полный ноль. Я ещё одну контору на нём знаю, но там его после меня принесли. >> и зараз пихать много файлов тоже нельзя). > сколько в граммах? "Большие" и "много" у всех свои. Мне хватило, чтобы я напоролся на это при _нормальной_ работе без извращений. Сейчас у меня этого чуда мысли образца 1980 года под рукой нет и я этим фактом вполне удовлетворён.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #74 Ответы: #83

83. Сообщение от anonymous yet another (?), 30-Май-20, 09:45	+/–
Немножко времени есть, подкину информации по P4. Работать с источниками в ней неудобно. Все характерные задачи при работе с источниками в ней решаются через ... . Её, похоже, изначально делали как "хранилище конфигураций". Однако затолкать что-то существенное (свежесобранная операционка, в скромном варианте) не получается --- ограничение по количеству файлов (файлов!) в транзакции. Снапшот источников ядра за одну транзакцию тоже, кстати, не проходит. Сравнить две "конфигурации" --- пляски с бубнами. Получить в двух разных местах две идентичные конфигурации --- тоже тот ещё квест. Решаемый, конечно. Но на хрена всё время бодаться с проблемами такого рода? Однако гвоздями прибит определённый workflow разработки, считаемый авторами единственно верным и незыблемым. [моё личное мнение].
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #82 Ответы: #84

84. Сообщение от пох. (?), 30-Май-20, 10:30	+/–
> Немножко времени есть, подкину информации по P4. > Работать с источниками в ней неудобно. Все характерные > задачи при работе с источниками в ней решаются через ... . ну а еще подробнее - какие задачи (мож у меня и нет таких?) и в чем неудобство. > Её, похоже, изначально делали как "хранилище конфигураций". хм, да, не мой случай (в смысле, вряд ли вышло лучше чем у svn, а той мне еще на двадцать лет хватит, благо не на пихоне писано) > Однако затолкать что-то существенное (свежесобранная операционка, > в скромном варианте) не получается --- ограничение по количеству > файлов (файлов!) в транзакции. Снапшот источников ядра за одну > транзакцию тоже, кстати, не проходит. ну то есть несколько тысяч - вполне пройдут? Идея внезапно-появившегося в проекте ядра линуха одним куском меня не особо и так впечатляет. Линус вас, кстати, тоже осудит - "порежьте чтоб в экран влазило и заверните каждую отдельным комитом" (представьте что он вам таки разрешил вмержить в ядро zfs?). > Сравнить две "конфигурации" --- пляски с бубнами. Получить > в двух разных местах две идентичные конфигурации --- тоже оно не умеет сравнивать r100101 и 100102 ? Или чекаутить 100103? Или вы что-то другое подразумевали? > Однако гвоздями прибит определённый workflow разработки, считаемый ну так описать-то его можете? Меня вот гитовый workflow не устраивает - да, он не прибит гвоздями, но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, не в сферическом вакууме. P.S. персистентные человекочитаемые (и желательно монотонно-растущие) версии нужны хотя бы для того, чтобы я - не видя вашего номерка перед глазами, он уже уехал за край страницы  - все еще помнил что он 100500. И насторожился бы, увидев в рабочей среде вместо него 100502. А гитовую бесполезность невозможно ни запомнить, ни сравнить без diff. e90e3cf e093ecf - это одна версия или разные? Попатчте ему лог уже кто-нибудь, чтобы он показывал вместо них HEAD, HEAD~ HEAD~22 - все равно никто ни с какими другими не работает. (отдельно убить того кто придумал эти дурацкие большие буквы) Будет вполне отражать тот вокфлоу, на который он заточен - "версия должна быть последняя или ненужно". Да, hg это попыталась решить, там никто не работает с хэшами, но эти версии локальны, что бесит - сегодня она у тебя 40, завтра мы перезалили репо - и та же версия стала 62. Понятно, почему  так, но крайне интересно было бы глянуть, как попытались сделать по-человечески.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #83 Ответы: #86, #92

85. Сообщение от пох. (?), 30-Май-20, 10:32	+/–
> Это сделали через mq, и так что лучше б не делали - > опять нужны ненужные знания о внутреннем устройстве инструмента. да, а histedit у нас бесполезное ненужно, потому что работает только в репозитории без веток - где они вообще такой нашли?!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65

86. Сообщение от anonymous yet another (?), 30-Май-20, 11:03	+/–
Я коротко. Время для трёпа закончилось. >> Немножко времени есть, подкину информации по P4. >> Работать с источниками в ней неудобно. Все характерные >> задачи при работе с источниками в ней решаются через ... . > ну а еще подробнее - какие задачи (мож у меня и нет > таких?) и в чем неудобство. Я реферат писать не буду. С источниками в P4 _мне_ работать было не то что неудобно, а невозможно. А я с ними работать могу и умею. Решал внешними средствами. > ну то есть несколько тысяч - вполне пройдут? Идея внезапно-появившегося в проекте > ядра линуха одним куском меня не особо и так впечатляет. Линус > вас, кстати, тоже осудит - "порежьте чтоб в экран влазило и > заверните каждую отдельным комитом" (представьте что он вам таки разрешил вмержить > в ядро zfs?). Во первых, задачи разные бывают. Во-вторых --- P4 неудовлетворительно отработало почти по всем полезным workflow/use-cases. Т.е. вынужденно жить я с ней мог, но это перманентная борьба на ровном месте. Оно мне надо? >> Сравнить две "конфигурации" --- пляски с бубнами. Получить >> в двух разных местах две идентичные конфигурации --- тоже > оно не умеет сравнивать r100101 и 100102 ? Или чекаутить 100103? Или > вы что-то другое подразумевали? Там модель другая. Поэтому употребляемые термины не подходят. По смыслу --- задачу решить можно, но сравнительно трудоёмко и достаточно глубоко предмет знать надо. >> Однако гвоздями прибит определённый workflow разработки, считаемый > ну так описать-то его можете? Ещё раз: хотите, берите и пробуйте. По мне --- не существует единственно верного workflow на все (даже только мои) случаи. > Меня вот гитовый workflow не устраивает - да, он не прибит гвоздями, > но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, > не в сферическом вакууме. Он не навязывает никаго workflow. Как построите работу, так и будет. Git мне в этом построении не мешает. >[оверквотинг удален] > ему лог уже кто-нибудь, чтобы он показывал вместо них HEAD, HEAD~ > HEAD~22 - все равно никто ни с какими другими не работает. > (отдельно убить того кто придумал эти дурацкие большие буквы) Будет вполне > отражать тот вокфлоу, на который он заточен - "версия должна быть > последняя или ненужно". > Да, hg это попыталась решить, там никто не работает с хэшами, но > эти версии локальны, что бесит - сегодня она у тебя 40, > завтра мы перезалили репо - и та же версия стала 62. > Понятно, почему  так, но крайне интересно было бы глянуть, как > попытались сделать по-человечески. Без комментариев. Математическими основами не владеете.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

87. Сообщение от Аноним (20), 30-Май-20, 11:18	+1 +/–
Это вариант раз git clone --no-checkout git sparse-checkout init --cone git sparse-checkout set <your dir> Это вариант два git clone --filter=blob:none --no-checkout Чё как, хорошо владеете гитом? Учиться никогда не поздно, да?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #30 Ответы: #98

89. Сообщение от Ilya Indigo (ok), 31-Май-20, 05:36	+/–
Я так и знал, что зайдя в ветку svn буду читать про git! :-) P.S. Ради этого и зашёл! :-)
Ответить | Правка | Наверх | Cообщить модератору

90. Сообщение от Аноним (-), 31-Май-20, 23:54	+1 +/–
> Очень хорошо сказано. Удваиваю. Гит сделан живым человеком для себя и людей. А вон то - корпорасами, на продажу.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #71

91. Сообщение от Аноним (91), 01-Июн-20, 00:00	+/–
> Меня интересует для себя, любимого, сделать - хорошо и удобно. Можно за деньги. Ну, затарься качественным бухлом и пистолетом. Можешь даже в кредит, это уже не важно. Что еще разумного посоветовать можно на глобусе где Торвальдс всех как обычно порвал? :) > И никогда-никогда не видеть убе...ских номеров комитов. Это изобрести мог > только один человек - тот, которому нахрен не нужна история, и, соответственно, vcs вообще. По ним на самом деле довольно удобно посылать тела совершенно не в теме в конкретные комиты.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #80

92. Сообщение от Аноним (91), 01-Июн-20, 00:06	+/–
> но что прикажете делать сделавшему pull вместо fetch+rebase? В реальной жизни, > не в сферическом вакууме. Если ты о профакивании изменений в дереве при git pull - то это сделать для начала гит как раз и не даст, зарубив pull пока как минимум не заныкаешь куда-нибудь свой креатив. > Да, hg это попыталась решить, там никто не работает с хэшами, но эти версии локальны, что бесит Ну вот на хэш можно ссылаться глобально - и это всегда корректно. Адресат посыла всегда пойдет в правильное место. А что такое r100102 - ему может говорить столько же сколько и sha1.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84 Ответы: #95

93. Сообщение от Роман (??), 01-Июн-20, 04:49	+/–
Используйте меркуриал, он хранит дифы
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4

94. Сообщение от Роман (??), 01-Июн-20, 04:51	+/–
Так такие системы как mercurial или git (если не зарываться) гораздо проще того же svn. Вот в чем штука. hg или svn - если тебе нужен совсем простой случай, делашь hg init или git init и все готово, а svn настраивать надо серверы (сервисы).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #97, #99

95. Сообщение от пох. (?), 01-Июн-20, 12:12	+/–
> Если ты о профакивании изменений в дереве при git pull - то это сделать для начала гит как раз лолшта? Эксперты опеннета... Заметно что гит они пользуют исключительно по методичке со стека, копи-пасть. git clone vi ... git add && commit git pull...ой! и хорошо если сразу заметил. А если через три итерации - как оно чаще всего и бывает? > даст, зарубив pull пока как минимум не заныкаешь куда-нибудь свой креатив. а это как раз _отдельная_ ненужная глупость афтырей. svn -даст, hg - даст. git заставляет заниматься ненужно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #92

96. Сообщение от пох. (?), 01-Июн-20, 12:15	+/–
> Мне ветки git понадобились даже когда просто по книжке занималась если копипастить из книжки - то тебе понадобится то, что там напишет автор книжки. Мне вот ветки не нужны практически никогда - я не собираюсь сливать свои изменения обратно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #56

97. Сообщение от пох. (?), 01-Июн-20, 12:23	+/–
> Так такие системы как mercurial или git (если не зарываться) гораздо проще > того же svn. покажите хоть один пример. > если тебе нужен совсем простой случай, делашь hg init или git > init и все готово, а svn настраивать надо серверы (сервисы). А, понятно. Можете уже не показывать. Эксперт опеннета в треде, ховаемся. svnadmin create  - разумеется чем-то супер-глобальным отличается от git init. Ага. Неумением прочитать ман из десяти строк. Зато urban legends наслушаться.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

98. Сообщение от пох. (?), 01-Июн-20, 12:30	+1 +/–
> git clone --no-checkout спасибо за 500 мегабайт неудаляемого мусора в .git Мне станет гораздо легче что 100 из них не будут сдублированы checkout'ом. > git clone --filter=blob:none --no-checkout мне нужен был blob - но только один, а не стопиццот. И не нужна его история изменений, в пятидесяти копиях. Его все равно нельзя сравнить diff'ом. > Чё как, хорошо владеете гитом? Учиться никогда не поздно, да? учиться выбирать инструмент, не требующий зазубривания миллиона идиотских ключиков, и решающи твои задачи, а не перпендикулярные твоим задачи божка-с-пальцовкой - вам уже поздно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #87

99. Сообщение от anonymous yet another (?), 01-Июн-20, 22:31	+/–
> Так такие системы как mercurial или git (если не зарываться) гораздо проще > того же svn. Вот в чем штука. Subvsrsion проще. Т.е. тривиальнее. И git и mercurial гораздо сильнее. Но hg попытался очеловечиться, tempora mutantur. Vulgrais.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #94

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

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