nagimov17 июн 2011 в 08:59

Системы управления версиями. Пособие для инженеров, художников и писателей

8 мин

35K

Atlassian * Подготовка технической документации * Системы управления версиями *

Из песочницы

+11

Комментарии 31

Evgin 17 июн 2011 в 09:12

Аббревиатура «СКВ» непривычная, ИМХО. Понятнее будет — VCS или SCM. «СКВ» — это все-таки «Свободно Конвертируемая Валюта»

nagimov 17 июн 2011 в 09:15

А также Системная Красная Волчанка, да. Для впервые знакомящихся с СКВ аббревиатуры VCS и SCM еще более непривычны.

Evgin 17 июн 2011 в 09:23

При чтении материалов в сети я все-таки намного чаще встречаю именно VCS и SCM, но никак не СКВ. Это сокращение СКВ(аналог VCS, не волчанка) увидел впервые — в вашей статье.

Но за статью Спасибо. Буду рекомендовать новичкам.

nagimov 17 июн 2011 в 09:30

В общем-то, эти сокращения — дело вкуса) Но, опять же, в вводной статье про СКВ не хочется грузить читателей кучей новых терминов. Новички сами разберутся со временем, а профессионалам данная статья не нужна вовсе.

librarian 17 июн 2011 в 10:27

Правильная аббревиатура СКР, то есть системы контроля ревизий.

int02h 17 июн 2011 в 09:25

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

GANGTA 17 июн 2011 в 09:33

Статья новичка, не будем придираться

k12th 17 июн 2011 в 09:37

Насчет *.bat-файлов и паролей: а почему не hgrc? см. секции alias, auth и defaults.

nagimov 17 июн 2011 в 09:45

Так, безусловно, грамотнее и правильнее, но целью статьи не было описание всего и вся, что есть в Mercurial. Без hgrc на первых порах вполне можно обойтись, со временем все обязательно найдется в мануалах.

k12th 17 июн 2011 в 09:47

Я бы все-таки упомянул про это. А то ведь народ так и будет писать батники, не зная, что можно проще:)

nagimov 17 июн 2011 в 10:15

Все-таки проще — эабить user:pass в батник, нежели ковырять конфиги. С точки зрения безопасности — конфиги, безусловно, лучше. Однако не хочется удлинять и так уже тяжелый текст.
Обязательно опишу в следующей части статьи, если возьмусь ее написать =)

k12th 17 июн 2011 в 10:18

Для задач, приведенных в статье, батники вообще не нужны — все делается через алиасы. И они все-таки поизящнее, имхо.

entze 17 июн 2011 в 10:51

Указанные категории на мой взгляд должны своим делом заниматься, а не батники ковырять. Гораздо полезнее было бы показать что-то с GUI, привести примеры использования. У Адоба ранее была система контроля версия, но в CS5 от нее зачем-то избавились. Хотя может в labs что и есть.

gaelpa 17 июн 2011 в 12:57

tortoiseHG, например?
Там, правда гуи тот еще. TortoiseSVN попроще будет.

nagimov 17 июн 2011 в 13:27

В статье вполне себе описан принцип работы с TortoiseHg. Полное описание в стиле «кнопка commit — это для коммитов, а кнопка push — для пушей» со скринами тех самых кнопок, это, простите, чересчур.

gaelpa 17 июн 2011 в 13:54

Это был ответ на комментарий entze, я упоминание ttHG заметил. Хотя скриншотов для показывания «нетехнарям» не хватает.

tampere 17 июн 2011 в 12:11

Надо бы написать ещё про диффы для изображений, вроде, делали такие.

fishbone 17 июн 2011 в 16:53

Спасибо! Давно хотел начать пользоваться подобной системой, но не знал с чего начать. А интересно, можно съэмулировать свое хранилище вместо bitbucket.org?

P.S. Подозреваю, что во второй строке push.bat должно быть «hg push Https://… ».

nagimov 17 июн 2011 в 17:15

Кажется, вы первый, кому это статья хоть чем-то поможет)

А интересно, можно съэмулировать свое хранилище вместо bitbucket.org?

Не вижу смысла, все что вы пушите в bitbucket — лежит и в вашем локальном репозитории.

во второй строке push.bat должно быть «hg push Https://… ».

Спасибо, исправил, потерялось при перепубликации.

fishbone 17 июн 2011 в 17:42

Под «давно хотел начать», я имел в виду «только сегодня думал». Ваша статья подвернулась очень кстати.
Сам не программист. Всегда, когда речь шла о репозиториях, думал, что это что-то сугубо профессиональное и сложное, и желания вникать особого не было. А тут вот оно как. :)

nagimov 17 июн 2011 в 17:50

думал, что это что-то сугубо профессиональное и сложное

Именно этот миф и хотелось развенчать. Надеюсь, получилось)

FSA 18 июн 2011 в 07:17

Кстати, может для кого будет открытием, но в офисах тоже есть своеобразная система контроля версий. Точно доступно в M$ Word, Writer, Calc. Обычно находится в меню Файл->Версии.

НЛО прилетело и опубликовало эту надпись здесь

elka_palka 18 июн 2011 в 16:31

заказывали систему с графическим интерфейсом и примочками?
пжалуста получите
http://www.gridironsoftware.com/
два минуса у системы:
— полные возможности за деньги
— не полностью стабильна на тяжелых проектах

MNU 20 июн 2011 в 18:59

Хочу заметить, что "Преимуществом этого метода является простота, недостатком – «разбухание» рабочих папок и неудобство использования. " для бинарных файлов (файлы ворда, эксела и пр.) остается также. Т.е. при каждой фиксации в репозитории будет лежать полная копия. Но второй тезис этим способом Вы решаете почти на все 90%.

Systerr 18 июл 2011 в 16:08

Интересует небольшой вопрос — скажем я хочу чтобы копии делались только когда в файле есть изменения. Грубо говоря я редактирую что либо, нажимаю на клавишу сохранить и где лежит файл он подхватывается системой контроля версий и архивируется. Интересуют средства файловой/операционной системы. Я понимаю что это можно сделать постоянно командой hg commit раз в секунд 10, но логики в то не очень много, и ресурсов много уйдет.
Меня больше интересует похожая система для офиса. Есть десяток компов, по smb на linux сервер работают с файлами. Как файл пере сохраняют хочется иметь версию старую в архиве. И так десяток версий каждого файла. Может есть варианты что можно к такому адаптировать?

nagimov 4 авг 2011 в 09:37

Простите за долгое молчание, лишь недавно прервал свое оффлайновое существование =)
По сути: подобного рода решений не встречал, на ум приходит лишь два костыля: как вы уже отметили, можно ежесекундно коммитить скриптом, либо ежесекундно проверять, изменилась ли дата изменения файлов и коммитить лишь измененные (сэкономим ресурсы); кроме того, при наличии такой возможности, команду save_file в офисных приложениях можно обернуть в макрос save_file+commit_file, в этом случае в фоне не будет висеть демона, «долбящего» файловую систему.

Systerr 8 авг 2011 в 12:02

Спасибо за ответ. Я немного подумал и мне на ум пришла такая штука как FUSE. Как я понял все вызовы по просмотру файлов, записи файлов, получения свойств будут происходит через мою прослойку, в которой я могу сделать все что захочу. И при записи файла я смогу старую версию скидывать в папку backup, которая будет лежать в той же директории. Для конечного пользователя это крайне прозрачно. Если я таки это сделаю, то постараюсь написать статью.

nagimov 8 авг 2011 в 12:16

Очень интересно! Оригинальное и нетривиальное решение =) Сам впервые слышу про FUSE.
Обязательно отпишитесь о результатах)

progchip666 28 окт 2016 в 20:29

Когда был новичком, а начал я именно с Мercurial хотел написать ИМЕННО ТАКУЮ ЖЕ СТАТЬЮ. Прзже понял что современные системы контроля версий к сожалению рассчитаны прежде всего на текствые файлы. Для обработки изображений, к примеру, они мало применимы, поскольку размеры архива и быстродействие системы будет очень быстро снижаться с каждой новой версией обработанных изображений.

progchip666 28 окт 2016 в 20:31

Кстати, для программистов СКВ просто незаменимая штука. Есть масса графических интерфейсов сильно облегчающих работу. Очень рекомендую TortouseHg

Зарегистрируйтесь на Хабре, чтобы оставить комментарий