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

Неделю назад я создал опрос, в котором хотел выяснить популярность контроля версий в нашем сообществе.

Результат


Количество опрошенных: 156.

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

+-----------+------------+------+
|   Ответ   | Количество |   %  |
+-----------+------------+------+
|    Да     |     115    | 73,7 |
|    Нет    |      41    | 26,3 |
+-----------+------------+------+

Какую систему контроля версий вы предпочитаете?

+-----------+------------+------+
|   Ответ   | Количество |   %  |
+-----------+------------+------+
| Git       |     71     | 57,3 |
| SVN       |     27     | 21,8 |
| Mercurial |     20     | 16,1 |
| CVS       |      2     |  1,6 |
| Fossil    |      1     |  0,8 |
| Perforce  |      1     |  0,8 |
| TFS       |      1     |  0,8 |
| VSS       |      1     |  0,8 |
+-----------+------------+------+


Детали

На данный момент опрос закрыт.

Форма опроса выглядела следующим образом:


Количество опрошенных со временем изменялось следующим образом:


Процент ответивших для второго вопроса брался от общего количества ответивших на этот вопрос, то есть от 124.

Некоторые в поле «Другой» указали TortoiseSVN и TortoiseHg, которые являются графическими клиентами для SVN и Mercurial соответственно. Я позволил себе присовокупить эти ответы к соответствующим системам.

Из тех, кто ответил «Нет», было 10 участников, которые выбрали систему.

Ссылки

Комментарии (34)

RSS свернуть / развернуть
А чего SVN обделил ссылкой на SVN-Book?
+1
  • avatar
  • Vga
  • 27 марта 2016, 19:19
Не знал, добавил.
0
Со статистикой все понятно, она мало чем отличается от прогнозов (большинство разработчиков использует СКВ, наиболее популярен GIT)

Вы лучше расскажите чем закончилась история с внедрением СКВ у Вас на работе.
0
Да пока ничем, разработчики не хотят, руководство никаких действий не предпринимает. Есть сервер, которым я активно пользуюсь и заставил пару молодых залить проекты в репозиторий. Но я еще статистику не показал. :)
0
Есть те, кто уже использует СКВ, и те, кто ещё нет.
С прошлой работы использую SVN. В итоге мой код лежит в моём репозитории на рабочей машине и в зеркале на моём сервере. Шансы на то, что всё подохнет одновременно сводятся к ядерной войне, тогда обоим машинам придёт пушистый зверёк, как, в прочем, и мне. Не понимаю, как можно комфортно жить без СКВ. Достиг результата — закрепил в СКВ. Прямо как сохранялки в играх. :)
+2
не поленитесь, настройте бекап svn-репозитория по крону, всего одна строка, например такая

svnadmin -q dump /путь/к/репозиторию | bzip2 -9 > /путь/к/бекапам/`date +%Y%m%d`-svn-backup.bz2
0
Оно ЕМНИП через сервер не работает, а локально можно и папку целиком сбэкапить.
0
да, это нужно делать на сервере, где svn развернут.

«Сбекапить папку» с репозиторием можно, но какие-то там были тонкости, которые svnadmin решает а просто бекап папки — нет. Уже не помню, может быть в современных версиях не актуально.
0
На самом деле, дамп — не рекомендуемый способ бэкапа. Рекомендуемый — svnadmin hotcopy. Если есть возможность гарантировать отсутствие доступа к репозиторию во время копирования — можно копировать непосредственно его папку любыми иными средствами. Дамп (в плане резервного копирования) полезен только для инкрементальных бэкапов, но они в некоторых случаях могут давать копию, не соответствующую репозиторию.
Дамп создавался для иных целей — в первую очередь это миграция репозитория.
0
Ну и вместо бэкапа можно держать еще несколько репозиториев, синхронизируя их с основным командой svnsync.
0
P.S. Хотя это и не совсем бэкап, зато таким макаром можно утянуть репоз, доступ к которому есть только по сети.
0
Собственно репа под вендой и VisualSVN, поэтому используется bat-ник, который выглядит так:
set now=%TIME:~0,-3%
set now=%now::=.%
set now=%now: =0%
set now=%DATE:~-4%.%DATE:~3,2%.%DATE:~0,2%_%now%
set svnadmin="C:\Program Files (x86)\VisualSVN Server\bin\svnadmin.exe"
set sevenzip="D:\Backup\7za.exe"
set repo_path="D:\Repositories\spirometr"
set backup_path = D:\Backup\spirometr_repo_backup
%svnadmin% hotcopy  %repo_path% D:\Backup\spirometr_repo_backup\%now% --clean-logs >> D:\Backup\spirometr_repo_backup\%now%svn.log
TIMEOUT 2
%sevenzip% a -tzip -bd D:\Backup\spirometr_repo_backup\%now%.zip_hdn D:\Backup\spirometr_repo_backup\%now% >> D:\Backup\spirometr_repo_backup\%now%.log
TIMEOUT 2
RD /q /s D:\Backup\spirometr_repo_backup\%now%

Ну а запускается всё это планировщиком заданий по-ночам.
0
SVN-бук говорит, что в поставке SVN есть скриптик на питоне, который занимается автоматизацией бэкапов на базе svnadmin hotcopy.

И это, какой смысл в переменных repo_patt, backup_path, если все пути все равно захардкожены?
0
Думаю смысл в том, что все «настройки» в одном месте. Я, собственно, скрипт не писал, я его просто содрал откуда-то, откуда не помню…
0
Какой смысл в настройках, если они игнорируются?
0
Да, действительно. Значит я извратил замысел автора.
0
Мне было бы интересно узнать, какой процент из пользующихся СКВ использует их больше чем для бэкапа и простой истории версий. Ну то есть использует несколько веток разработки, потом мерждит отлаженные фичи с основной веткой и т.д. Если разработчиков больше одного — там понятно, востребовано. А вот для себя? Я вроде как и пользуюсь, а по сути, то же самое я мог бы делать архиватором, периодически пакуя исходники в архив с датой в названии. Что я раньше и делал. Ну удобства может чуть прибавилось, если только.
0
  • avatar
  • ACE
  • 28 марта 2016, 01:55
Даже только эти две функции оно выполняет на порядки лучше мешка архивов.
+1
существование СКВ как-бы намекает, что не бывает «простых историй версий».

Самая обычная проблема с которой сталкиваются чаще всего — пол года назад это работало, а месяц назад перестало. Банально найти в этой самой «простой истории» место, посмотреть что изменилось, и откатить только это изменение — выливается в кучу ручной работы diff'ом, patch'ем и так далее. Вот это «удобства чуть прибавилось», если пересчитать в затраченное время, окупается на второй-третий-пятый раз поиска чего-либо в «простой истории».

А дальше, если уже пользуетесь СКВ, ветки начиная с svn — почти так-же просто, как «еще одна папка с исходниками», а в hg/git — еще проще. И опять, одна-две ситуации, когда нужно что-то исправить в достаточно старом релизе окупает затраты на изучение-внедрение
+3
Мне было бы интересно узнать, какой процент из пользующихся вычислительными машинами использует их больше чем для вычислений и простых алгоритмов. Ну то есть использует несколько параллельных потоков вычислений, потом мержит полученные результаты и т.д. Если процессоров больше одного — там понятно, востребовано. А вот для себя? Я вроде как и пользуюсь, а по сути, то же самое я мог бы делать арифмометром, периодически записывая результаты на бумажке с пояснениями. Что я раньше и делал. Ну удобства может чуть прибавилось, если только.
-1
Ну то есть использует несколько параллельных потоков вычислений, потом мержит полученные результаты и т.д.
Хм, по моим наблюдениям как раз большинство программ не умеют эффективно использовать потоки (не говоря о асинхронных операциях ввода/вывода). Просто многие программисты подсознательно боятся асинхронных операций (зная какие могут возникнуть проблемы) и избегают распараллеливания. Зачатую наоборот создавая узкие места ставя critical section просто «на всякий случай».

Так что аналогия сомнительная :)
0
Я все крупные изменения делаю в отдельной ветке. Это позволяет фиксировать промежуточные результаты в этой ветке (при этом держать «чистой» основную ветку) до того момента пока полностью все не сделаю и не протестирую.
+2
Все была мысль, что надо что то подобное начать практиковать. Но все как то и незачем. По привычке держу все в голове и даже комментарии уже не пишу. Благо проекты простые и мелкие.
+1
Попробуй, тебе понравится. Плюс приватный репозиторий где-нибудь на битбакете или гитхабе и даже смерть домашнего компа не приведет к потере сорсов.
0
Я гитхаб как то не осилил ваще. Что там куда там ничерта не понятно. А сорцы у меня лежат в дропбоксе и один хрен бэкапятся автоматом на хренову кучу машин.
+1
Попробуй битбакет. Он как по мне несколько более user friendly.
0
Мне показалось наоборот. В гитхабе мне не нравится только то, что он git only.
0
В простых и мелких проектах часто нужно что то исправить под конкретную задачу (был вот у меня rgb контроллер с управлением по usb, а на днях резко потребовался такой же но с rs-485). можно выделить в репозитории отдельную ветку под это дело и не создавать новой копии. при грамотных коммитах можно изменения/исправления применять ко всем веткам сразу. грамотнее конечно для этого привязывать библиотеки из общих папок, но это затрудняет развертывание на новом рабочем месте.
0
А то есть я правлю какую нибудь отдельную, но общую для всех веток либу и она везде правится?
0
нет. точнее хз где как, но в меркуриал надо малость хитрить и часто коммитить, чтоб можно было это делать. то есть редактирование какого нибудь общего файла делаем отдельным коммитом и применяем это изменение ко всем веткам по отдельности.
0
Нет, она поправится в тех ветках, где вы примените изменение.
0
стоит заметить что не каждое изменение можно корректно применить.
0
точнее не всегда
0
На пример случая выше, надо держать ветве где нет реализации 485 или юсб, ветвь с реализованным юсб и ветвь с 485. Тогда при реализации фичи не связаннлй ни с тем ни с другим надо создать под нее ветвь из мастер ветви, реализовав её, надо смержить её в обе ветви.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.