LINUX.ORG.RU

Используемые системы контроля версий

 ,


1

2

В связи с недавней новостью (Bitbucket прекращает поддержку mercurial) стало интересно, какими системами контроля версий пользуются пользователи LOR. Скорее всего первое место по популярности займёт git, но это не снижает ценности других систем в зависимости от потребностей в рамках работы над каким-либо проектом.

Постарался внести в список наиболее часто упоминаемые, как мне кажется, VCS. Доступен мультивыбор.

p.s.
Вариант «храню архивы, не пользуюсь VCS» включает в себя и просто создание копий директорий и/или файлов без архивирования.

  1. Git 739 (87%)

    ********************************************************************************************************************************************************************************************************************************************************************************************************************************

  2. Subversion (SVN) 115 (14%)

    *************************************************

  3. Mercurial (Hg) 80 (9%)

    **********************************

  4. храню архивы, не пользуюсь VCS 62 (7%)

    **************************

  5. не храню промежуточные состояния проекта 40 (5%)

    *****************

  6. CVS 24 (3%)

    **********

  7. Perforce 17 (2%)

    *******

  8. Fossil 16 (2%)

    ******

  9. другая VCS (в комментариях) 16 (2%)

    ******

  10. Azure DevOps (Team Foundation) Server 10 (1%)

    ****

  11. Darcs 9 (1%)

    ***

  12. Bazaar 8 (1%)

    ***

  13. Dat 1 (0%)

  14. Monotone 1 (0%)

Всего голосов: 1138, всего проголосовавших: 850

★★★★★

Проверено: cetjs2 ()
Последнее исправление: cetjs2 (всего исправлений: 3)

Архивы

храню архивы, не пользуюсь VCS

Как этот пункт вообще попал в опрос? Архивы и СКВ вещи ортогональные. У меня есть архивы, и я использую СКВ.

Camel ★★★★★
()

Пока не пользуюсь, но внимательно слежу за развитием проекта: https://pijul.org/

zabbal ★★★★★
()

винрар, винрар,
а не, стойте.
бтрфс, во!

darkenshvein ★★★★★
()
Ответ на: комментарий от RiseOfDeath

git-svn

А еще бывает жуткий легаси который с SVN`а переносить никто не собирается. Просто по-тому что «и так сойдет», «это куча геммороя», «это че-то там надо делать», «это простой» и т.п.

В таких случая часто даже те кто пользуется SVN'ом пользуется git'ом, потому что git-svn позволяет локально иметь git, а на центральном сервере SVN. Я этим пользовался на позапрошлой работе, лучше git-svn чем просто SVN.

Camel ★★★★★
()
Ответ на: git-svn от Camel

Первый раз про git-svn слышу. Пойду погуглю.

RiseOfDeath ★★★★
()
Последнее исправление: RiseOfDeath (всего исправлений: 1)
Ответ на: комментарий от grem

Merge problem

Почему не darcs?

Там, кажися, была какая-то эпичная проблема с алгоритмом слияния с экспоненциальной сложностью.

Ах да, вот она, легко находится.

В пихуле хвастают, что решили, и всё остальное сумели не засрать, мол у них все алгоритмы не хуже h*log(h), где h — длина истории. А быстрее, говорят, и не надо, потому что всё равно упрётся в файловую систему, где сложность такая же.

Camel ★★★★★
()
Ответ на: Архивы от Camel

Там же написано, архивы — в смысле руками копируешь файлы в другое место.

question4 ★★★★★
()
Ответ на: Merge problem от Camel

Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future.

Меня терзают смутные сомнения

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

ЯННП

Yes, we solved the exponential merge problem. The only caveat is that Pijul does not (yet) have an equivalent of darcs replace. In other words, Pijul works in polynomial time for all patches that systems other than darcs know of. We’ve not yet thought all the theory of this through, but it might be added in the future.

Я английский язык нехорощо знаю. Эт чо, они как бы решили проблему, но решение не работает? Муть какая-то написана. Что такое «all patches that systems other than darcs know of»? И последнее предложение до запятой слишком сложное для меня.

Camel ★★★★★
()
Ответ на: ЯННП от Camel

Я тоже ничего не понял. Для меня абзац выглядит так «мы решили проблему, но пока не поняли как».

Что-то вроде: слияние работает за полиноминальное время для патчей характерных для других систем, но не патчей характерных для darcs. Ээээ, разве у них патчи не схожи с теми, что в darcs?

grem ★★★★★
() автор топика

emerge --sync через git. :)

dimgel ★★★★★
()

Своя самодельная VCS на LabVIEW, в основном для разработки Metaprog.

metaprog
()

Голо-совалку😉 лор надо править. Даёт возможность присунуть повторно 😜

Верните уже вечный опрос - он был фишкой

MKuznetsov ★★★★★
()
Ответ на: комментарий от grem

Я тоже ничего не понял

Ну они пишут, что для тех слияний которые эквивалентны таким, которые не в darcs (т.е. таким как в git) они проблему решили. А как сделать для любых они ещё не придумали.

разве у них патчи не схожи с теми, что в darcs

Вопрос из разряда «разве выражение 2+2 не схоже с x+y?». Там и там сложение же.

no-such-file ★★★★★
()

SVN чтобы упорядочить исходники над которыми работаешь с разных компов. И был еще доступ для партнеров

Git так и не понял, кажется странной идея что каждый комп это репозитарий, вот это мне точно не нужно.

tnemo
()
Ответ на: комментарий от tnemo

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

grem ★★★★★
() автор топика
Ответ на: комментарий от slovazap

сразу становится понятно что апстриму контрибуторы не нужны.

Будемо честными — такие контрибьюторы не способны внести серьёзный вклад в проект.

Подготовка и тестирование серьёзного патча занимает на порядки больше времени, чем нужно на отправку патча даже на непривычных SCM.

И если человека останавливает всего лишь собственная инфраструктура проекта, то значит, что он не хочет, чтобы патч попал в апстрим.

anonymous8 ★★
()

Git рулит. Зачем всё остальное напридумывали, и кому оно нужно?

lucentcode ★★★★★
()
Ответ на: комментарий от grem

Ты сказал непонятно, можно и в коммит включить только 5 из 15 измененных файлов, тоже выборочно получается :)

Aber ★★★★★
()
Ответ на: комментарий от tnemo

Git так и не понял, кажется странной идея что каждый комп это репозитарий,

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

В гите ничего не стоит переключится на релиз, который вышел несколько месяцев назад, чтоб внести нужные фиксы, а потом применить эти фиксы в текущем бранче, где идет разработка следующей версии.

Aber ★★★★★
()
Ответ на: комментарий от anonymous8

Подготовка и тестирование серьёзного патча занимает на порядки больше времени, чем нужно на отправку патча даже на непривычных SCM.

Чем же я этот ‘‘серьёзный патч’’ готовить буду, если в проекте вместо системы контроля версий какой-нибудь svn, в который коммитить мне никто никогда не даст.

d_a ★★★★★
()
Ответ на: комментарий от d_a

Готовь в чём угодно. Потом просто патчи по почте отправляешь.

Я и патчи созданные в git для проекта в git отправлял по почте, когда у того проекта проблемы с инфраструктурой были пару дней.

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

То есть выкинуть нерабочие поделия и взять git? Чтож, я не могу согласиться больше. Глядишь и время на подготовку серьёзных патчей снизится.

d_a ★★★★★
()
Ответ на: комментарий от d_a
  • Где я такое сказал?
  • Если ты активный разработчик - тебе просто дадут доступ.

Есть куча репозиториев, которые поддерживают тот же git, но пул реквест через формочку как на github ты там не отправишь.

Ты ещё предложи библиотеки выбирать не чтобы самому удобнее было, а ориентироваться на потенциальных ментейнеров.

grem ★★★★★
() автор топика
Последнее исправление: grem (всего исправлений: 2)

git, svn для того что в нем писалось не мной

Slackware_user ★★★★★
()

Что можно использовать для версионирование, например, исходников мультфильмов, видеопроектов и проектов Ardour? Чтобы была возможность совместной разработки?

Пример на гите: https://code.lor.sh/km2/helicopter

gtk3 ★★★
()
Последнее исправление: gtk3 (всего исправлений: 2)
Ответ на: комментарий от d_a

LLVM всё ещё в процессе миграции на git с svn, скоро закончат. Сейчас на github зеркало основного репозитория svn. И ничего, как-то справлялись.

grem ★★★★★
() автор топика

Subversion (SVN)
Mercurial (Hg)

это для идиотов, которые не знают, что svn - это subversion, а hg - mercurial, и отмечаются в «другоая vcs»?

dummy ★★
()
Ответ на: комментарий от Crocodoom

3,5 анонимуса

Пихуль. Но не знаю, есть ли реальные пользователи.

Их нет. У самого пихуля на nest.pijul.com 40 подписчиков, у большинства из них 1 репозитарий под названием «test».

А так, будете в гнезде заходите.

Camel ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.