Проекту NetBSD исполнилось 20 лет!

Век живи, век учись. Хорошо, а теперь пожалуста «апнуть» и так что бы мусора не осталось?

PS: Я не хочу умалять преимущества Git, но и CVS imho большинством незаслуженно забыт. У того и у того есть свои преимущества.

вся его подноготная — это old plain text (точнее даже ed-script)

Я когда-то давно работал в компании разработчиков на 50, и там использовался CVS. Он тормозил! Даже на не очень больших веб-проектах. Помню cvs tag долго работал по одному файлу. Как на нем может вестись разработка ядра?

Как на нем может вестись разработка ядра?

И не только ядра, но и целой системы! (И как минимум двух: Net/Open)

Помню cvs tag долго работал по одному файлу.

Какие-то другие затыки? Чесно признаться с тормозами ещё не встречался, но и CVS на 50 чел не поддерживал.

У меня в стрекозе git и cvs(для доп. репы). Что могу сказать - по времени git быстрее в несколько раз, хотя ему приходится тянуть сорцы системы + порты из основной репы, которая больше в 3 раза. Git работает полминуты-минуту. А пока csup ворочается, я успеваю сходить покурить, и то не факт, что прихожу к окончанию процесса, часто приходиться ишшо подождать. Как в нетке обновляют все через cvs - плохо представляю. Бедные, мне их жалко.:)

Какие-то другие затыки?

Эмм... Нельзя создавать пустые каталоги, при переименовании или копировании файлов не хранится предыдущая история. Да даже Subversion куда лучше, в том числе и по производительности. По-моему просто никто не хочет возится с переездом)

Ну.. наверное «мусор» останется: то есть при pull останутся коммиты, что есть + новые коммиты (коммит - обьект гита).

Вот так нагляднее:

# создаем новый репозиторий в /tmp/repo1
elvenfighter /tmp/repo1 $ git init
Initialized empty Git repository in /tmp/repo1/.git/

# "Наполняем" его коммитами (100 штук)
elvenfighter /tmp/repo1 master # $ for i in {1..100}; do git commit --allow-empty -m "Commit #${i}"; done 
[master (root-commit) 3802ed5] Commit #1
[master 634aad3] Commit #2
...
[master bce2d0a] Commit #100

# клонируем repo1 в /tmp/repo2 с глубиной 1
elvenfighter /tmp $ git clone --depth=1 file:///tmp/repo1 repo2
Cloning into 'repo2'...
remote: Counting objects: 3, done.
remote: Compressing objects: 100% (2/2), done.
Receiving objects: 100% (3/3), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Resolving deltas: 100% (1/1), done.

# Вот наши коммиты из repo1: ${глубина_клона} + 1
elvenfighter /tmp/repo2 master= $ git log --pretty=oneline
bce2d0a79f9e9a89663460d739c26e852b6aede3 Commit #100
2a57f881c51468b0a9432b6e633d9b9b6642e181 Commit #99

# Тем временем добавляем в repo1 новые коммиты (10 штук: 101..110)
elvenfighter /tmp/repo1 master $ for i in {101..110}; do git commit --allow-empty -m "Commit #${i}"; done 
[master dd9c9b3] Commit #101
...
[master d690822] Commit #110

# "ап"
elvenfighter /tmp/repo2 master= $ git pull
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 10 (delta 9), reused 0 (delta 0)
Unpacking objects: 100% (10/10), done.
From file:///tmp/repo1
   bce2d0a..d690822  master     -> origin/master
Updating bce2d0a..d690822
Fast-forward

# В repo2 имеем 2 + 10 коммитов 
elvenfighter /tmp/repo2 master= $ git log --pretty=oneline
d69082216cdc876fb16ab1866b59dd12dedaab9a Commit #110
b0b50a03c4c3459404fddcd03f65465b2971d24b Commit #109
1b401cc90ddb1c8b2eb88fd2db8e530ad0f6ccdb Commit #108
155ce9d94e8b1d2e79f0f338ee676bb9c1285a1e Commit #107
46820559bdb7752eb41bd1f3d8eaf81d0572eaf5 Commit #106
439535d4babe239679c323a7e4c4fd6ecab60042 Commit #105
d16ae3530b621542cc4186adccd86fecec011c5f Commit #104
d9997ed189ae0b17740d9223e9a83e28268de18f Commit #103
44947aefd34c99f62037b49a659e85bad3a795b5 Commit #102
dd9c9b390a686fb0d09ce0f057c657380b078b11 Commit #101
bce2d0a79f9e9a89663460d739c26e852b6aede3 Commit #100
2a57f881c51468b0a9432b6e633d9b9b6642e181 Commit #99

Большое спасибо за развёрнутый ответ! Но я всё таки придерживаюсь мнения, что для подобных проектов, когда в основном нужен только актуальный код, а история не очень интерессна (и занимает место, что на embedded devices и подобном может быть критично), CVS/SVN предпочтительней.

Если можно вопрос (честно, лень самому искать): если я не ошибаюсь в Git есть возможность организовать эмуляцию SVN (CVS?)?

По-моему просто никто не хочет возится с переездом.

Это скорей всего самое главное. (Работает — не трогай! ☺)

Git есть возможность организовать эмуляцию SVN (CVS?)?

На сколько я знаю есть две такие фичи:

• gitsvn - двунаправленная связь git <-> svn - меняемся коммитами между VCS (https://www.kernel.org/pub/software/scm/git/docs/git-svn.html)
• git config alias - делаем алиасы для гитовых комманд. То есть можно «проэмулировать» работу SVN/CVS комманд с помощью команд гита (конечно «эмуляция» будет далека от оригинала, но хоть что-то) (https://git.wiki.kernel.org/index.php/Aliases)

CVS забыта как раз заслуженно – Subversion в той же категории однозначно лучше.

Спасибо ещё раз, надо будет внимательней глянуть.

На сайте у них список такой есть

Я тоже в свете последних линуховых тенденций попробовал вчера в qemu поставть открытобздю. Установилось все, а после ребута кещельбе мещельбе быдыдыщ qemu говорит что дескать загрузочного диска не найдено.

Придется попробовать на реальном железе, но что то мне говорит, что где то я чего то не понял

Отличный проект, пусть и дальше развивается. Удачи разработчикам.

Поздравляю братьев по разуму!

И вот девчонки стоят в сторонке,
Платочки в руках теребят.
Оказалось не любит девчонок
Маководов наш дружный отряд.

если будешь ставить на реальное железо то, зайди в шелл и выполни: # fdisk -B wd0

Да и диску дай имя такое при установке, а то первый раз оно вроде имя диска выбирает

Open песенки поют.

Спасибо, учту.

cvs

юникс - это возможность выбора

у меня баттхёрт от всего этого если не про линукс говорят

fixed

https://wiki.freebsd.org/GitDrawbacks

beastie

git clone --depth=2 http://repo

Так и знал что кто-нить это скажет :). Из мана:

      --depth <depth>
           Create a shallow clone with a history truncated to the specified
           number of revisions. A shallow repository has a number of
           limitations (you cannot clone or fetch from it, nor push from nor
           into it), but is adequate if you are only interested in the recent
           history of a large project with a long history, and would want to
           send in fixes as patches.

Т.е. это предназначено исключительно для копирования снапшотов, а не для работы.

А их небось лицензия не устраивает на git?

Может и так. Ждём opengit :)

пофикси, плз

Я как раз по доброму пожелал BSD умирать подольше. А вот у тебя батхерт, это да. :)

как раз для работы (посылания патчей) это и годится

Хм, видимо, я неправильно понимаю маны (или они криво написаны). Мне казалось там написано что push работать не должен. Но, по крайней мере без коммитов, у меня не ругается.

Хм, удалось запушить из shallow репозитория. Чтож, netbsd может переходить на git :)

они вроде по fossil угорали.

это я так тонко троллю.

Не только они, опен тоже с cvs никуда съезжать не собирается.

Кому надо, давно уже съехали.

http://xenocara.org/cgit/src/

все равно, официальное дерево - cvs, а git - для работы, что, однако, уже как бы намекает.

На что намекает? CVS это традиции и духовные скрепы, проект не желает скатываться в пучины бездуховности и морального разложения, вот и всё.

Т.е. это предназначено исключительно для копирования снапшотов, а не для работы.

Задача и была в создании снапшота верхушки.

А вам не кажется, что в самом названии заложен некий лозунг..
Как тут не вспомнить капитана Врунгеля..

Но я всё таки придерживаюсь мнения, что для подобных проектов, когда в основном нужен только актуальный код, а история не очень интерессна (и занимает место, что на embedded devices и подобном может быть критично), CVS/SVN предпочтительней.

Это ошибочное мнение. Если история не нужна - tar.{gz,bz2,xz} . Если же нужна, то git даст сжатие истории плюс контроль целостности в одном флаконе. Как раз использование CVS/SVN чревато неоправданно большими потерями свободного места в ПЗУ на историю, а по джитовским бранчам свн плачет кровавыми слезами.

если я не ошибаюсь в Git есть возможность организовать эмуляцию SVN (CVS?)?

Да, есть git-svn, и не знаю, чтобы я без него делал.. В том смысле, что как раз знаю, и очень рад, что мне это делать не приходится.

purulent cunt

Of course it runs NetBSD!

Проект стар как мир)))

кто-нибудь для raspberry pi собрал его??

вроде утверждается что портирован.