По ходу действия хочу подчеркнуть, что Subversion, хотя и является инструментом в первую очередь для программистов, может использоваться и людьми, от программирования достаточно далёкими. Если вы имеете дело с документами в формате LaTeX, то никто не запрещает использовать Subversion или любую другую систему контроля версий: LaTeX в общем тоже язык программирования оформления документов, так что использование Subversion будет так же продуктивно.
Пример, который я люблю приводить своим студентам - их диплом. Большой документ, много текста и картинок. Обычно написание диплома в форматах, к тому не предназначенных, приводит к кошмару вида diplom-pupkin-last-best-new-cool-version45.doc с полным непониманием того, что изменилось в 44 версии и как посмотреть, много ли поменял научный руководитель в тексте с прошлой встречи. Subversion, будучи использованной вместе с LaTeX, избавляет от головной боли и других нежелательных расстройств при написании диплома или (того хуже) диссертации.
Наполнение репозитория Subversion
Репозиторий, созданный командой:
$ svnadmin create /usr/local/svn/newreposнужно наполнить свежими данными. Для этого есть команда svn import это быстрый способ скопировать не версионированное дерево файлов в хранилище, например:
$ svn import mytree file:///usr/local/svn/newrepos/some/project \
-m "Initial import"
Adding mytree/foo.c
Adding mytree/bar.c
Adding mytree/subdir
Adding mytree/subdir/quux.h
Committed revision 1.
Стоит заметить, что после завершения импорта, оригинальное дерево файлов не конвертируется в рабочую копию. Для того, чтобы начать работать вам необходимо создать новую рабочую копию (svn checkout) дерева файлов.
Добавление новых файлов и каталогов в репозиторий Subversion
Например, вы создаёте крупный документ в ЛаТеХе, и появился новый каталог с новыми текстами или картинками. Как их добавить в Subversion репозиторий? Очень просто:
$ svn add temp A temp A temp/Lit_obzor2_edt.tex
Теперь смотрим на статус наших файлов и видим, что против них стоит буква А - значит, они Added, то есть добавлены:
$ svn status
? image
? biblio
? optcodeimages
M draft_PhD_Konnik.dvi
! PhD_Konnik.log
A temp
A temp/Lit_obzor2_edt.tex
! PhD_Konnik.toc
M PhD_Konnik_chapter_results.tex~
! PhD_Konnik_chapter_introduction.dvi
! PhD_Konnik.aux
! PhD_Konnik.bbl
! draft_PhD_Konnik.log
! PhD_Konnik.blg
! draft_PhD_Konnik.toc
! draft_PhD_Konnik.aux
! draft_PhD_Konnik.bbl
M PhD_Konnik.dvi
! draft_PhD_Konnik.blg
M PhD_Konnik_chapter_results.tex
! PhD_Konnik_chapter_introduction.log
Они будут помещены в репозиторий при следующей отправке (commit).
Обновление рабочей копии до состояния репозитория
Файлы, находящиеся в репозитории свежее, чем у вас в рабочей копии. Дубовый вариант заключается в том, чтобы удалить свою рабочую копию и сделать chekout из репозитория. Это проходит, если репозиторий только ваш и вы уверены, что никаких изменений в рабочей копии вы не потеряете. Но есть вариант и получше:
$ svn update UЭто обновит вашу локальную копию до ревизии, которая находится в репозитории SVN. После этого можно приступать к работе с файлами, так как они обновлены до последней версии.
biblio/my.bib U
biblio/my.bib.bak
Updated to revision 9.
Латинские буквы перед именем файла имеют свой сакральный смысл, скрытый в недрах документации сокрушительных размеров (кстати, документация очень хороша, и есть даже частичный перевод на русский тут). Собственно, буква означает действие, которое выполнил Subversion для приведения рабочей копии в актуальное состояние:
U foo
U
pdated — Файлfoo
был обновленA foo
A
dded — Файл или директорияfoo
былидобавлены в рабочую копию.
D foo
D
eleted — Файл или директорияfoo
былиудалены из рабочей копии.
R foo
R
eplaced — Файл или директорияfoo
былазаменена в рабочей копии; это значит, что
foo
был удален, а новый элемент с таким же именем был добавлен.G foo
mer
G
ed — Файлfoo
получил новые изменения из хранилища, однако ваша локальная копия содержит ваши
изменения. Либо изменения не пересекаются, либо они точно такие же, как ваши локальные изменения, поэтому Subversion успешно выполнил слияние изменений хранилища с файлом.C foo
C
onflicting — Файлfoo
получил от сервера конфликтующие изменения. Изменения с сервера пересекаются с
вашими изменениями фала.
Просмотр истории ревизий в Subversion
Часто нужно просмотреть, что и как редактировалось - для этого при отправке новых данных в репозиторий (commit) есть смысл писать содержательные и осмысленные комментарии. Если это так, то можно многое узнать о том, что и когда редактировалось:
$ svn log --revision 1:3что значит: выдать лог ревизий с первую по третью. Увидим:
----------------------------------- r1 | penta4 | 2008-06-03 15:49:21 +0400 (Втр, 03 Июн 2008) | 1 line Initial dissertation state
-------------------------------- r2 | penta4 | 2008-06-03 16:56:01 +0400 (Втр, 03 Июн 2008) | 3 lines Committed new editions
--------------------------------- r3 | penta4 | 2008-06-03 16:58:12 +0400 (Втр, 03 Июн 2008) | 2 lines incremental ------------------------------------------------------------------------
Очень удобно, когда нужно кому-то отправить историю правок вашей программы или документа.
Просмотр изменений в Subversion
Например, нужно просмотреть изменения, происшедшие со второй по четвёртую ревизии. Легко!
$ svn diff --revision 2:4 PhD_Konnik.tex > PhD_Konnik.tex.diff.r2-4Это выведет нам в diff-файл все изменения, а ваш любимый текстовый редактор их с удовольствием подсветит для более удобного просмотра.
Отмена изменений в Subversion
Вы сидите и правите какой-то документ - и тут с ужасом понимаете, что правите _не тот_ документ. Не беда - переносите изменения во временный файл, а для того документа, который вы нечаянно испортили, пишем:
$ svn revert UMNIK08-Report-01/Report-01-sub1-shortened.texПосле этого SVN вернёт файл Report-01-sub1-shortened.tex в то состояние, в котором он находится в репозитории.
Reverted 'UMNIK08-Report-01/Report-01-sub1-shortened.tex'
Копирование или перемещение нескольких файлов в SVN/Subversion (multiple targets move/copy in SVN)
Странно, однако SVN не понимает символов типа *, так что ваша попытка сделать так:
$ svn mv MCBC/*jpg LinuxImages/приведёт к ошибке:
svn: Client error in parsing argumentsЧтобы не перемещать все файлы по одному, воспользуемся _ваша любимая оболочка тут_, в моём случае это Bash:
for i in *.cs ; do svn mv $i newFolder/ ; doneКонечно, если в вашей операционной системе есть нормальная консоль :-)
Выдача определённой правки файла из репозитория
Например, нам очень нужно посмотреть, каким был файл при второй правке. Для этого пишем:
$ svn cat --revision 2 PhD_Konnik.tex > PhD_Konnik.tex.v2То есть выводим результат второй правки файла PhD_Konnik.tex и записываем его в файл PhD_Konnik.tex.v2 для дальнейшего просмотра.
Восстановление удалённых файлов в Subversion
Ну и наконец самое страшное: вы приказали Subversion удалить файл из репозитория, а потом кто-то вам говорит: этот файл нужно вернуть. На самом деле, файл, который вы удалили из SVN, никуда не делся: элемент исчезает из правки
HEAD,
но продолжает существовать в более ранних правках. Так что вопрос "как восстановить удалённый файл в Subversion" имеет довольно простой ответ: скопировать его из последней правки, где он был.Главное вспомнить, как этот файл назывался. Если помним хотя бы частично имя файла (например, overview), то можно попросить Subversion вывести все упоминания о правках этого файла так:
svn log -v | grep spatialcoh -A 5 -B 5Здесь параметры для grep такие: -A 5 это выдача 5 строк после (After) совпадения, -B 5 это 5 строк до (Before) совпадения. Получим длинный вывод вида:
spatialcoherencyexplained.eps 436 | penta4 | 2009-12-02 15:39:30 +0300 (Срд, 02 Дек 2009) | 2 linesКрасным подчеркнул я: видно, что файл spatialcoherencyexplained.eps удалён в правку 436, и теперь хотим его восстановить. Смотрим, в какой правке файл был удалён - в 436, значит, в 435 есть его последняя копия. Восстанавливаем:
Changed paths:
M /PhD_Konnik_autoreferat.tex
M /PhD_Konnik_chapter_opticalcoding.tex
M /PhD_Konnik_chapter_overview.tex
D /images-opticalcoding/spatialcoherencyexplained.eps
M /images-opticalcoding/sxemacorrelator3.eps
M /latex.py
M /svnstatus.tex
M /zagashnikPhD_Konnik.tex
--
M /biblio
A /formaldocs/disserDocs.tif.7z
A /images-opticalcoding/PSFdotssize.eps
M /images-opticalcoding/PSFoutofLambdaDeltaLambdavsfromNumberOfElementsPSFRus.ps
A /images-opticalcoding/auxilaryImagesForDisser.svg
A /images-opticalcoding/spatialcoherencyexplained.eps
M /zagashnikPhD_Konnik.tex
TENGIBLE changes:
- autoreferat is improved slightly;
- Spatial coherency is improved
svn copy --revision 435 file:///phdthesis/images-opticalcoding/spatialcoherencyexplained.eps spatialcoherencyexplained.epsВсё, теперь файл появится снова, вместе с историей правок (что важно) и вы можете его править дальше.
Ссылки
Разумеется, это далеко не все возможности Subversion - в данном посте не рассмотрены возможности создания и слияния веток, но в качестве быстрого введения должно хватить. Больше есть в переведённом на русский исчерпывающем мануале тут.
Пересел с SVN на Git, не жалею... Из плюсов - распределенность, не нужен постоянно онлайн сервер, только одна папка .git в корне проекта, а не в каждой папке как .svn, прозрачная работа с тэгами и ветками
ОтветитьУдалитьрекомендую
полностью с Анонимом согласен нужно прогрессировать...
ОтветитьУдалитьhttp://total-sentences.blogspot.com/
++
ОтветитьУдалитьUse Git, Lik and force will be with you.
А уж работа с LaTeX+git - вообще сказка! Очень удобно работать над отдельными главами в отдельных ветках.
ОтветитьУдалитьАвтор, открой для себя Git!
ОтветитьУдалитьА вот мне SVN как-то привычнее. В KDE хороший GUI, не напрягаюсь на предмет запоминания команд.
ОтветитьУдалить@ Анонимный, 07.12.2009 2:43:00
ОтветитьУдалитьПересел с SVN на Git, не жалею...
Ребята, я не могу использовать git, т.к. под него нет НОРМАЛЬНЫХ виндовых графических клиентов. Кроме того, тут ещё макинтошевцы заходят. Короче, использовать GIT не выходит.
@ Анонимный, 07.12.2009 8:36:00
Use Git, Lik and force will be with you.
Can you suggest a good, working git GUI-based program? For Windows (C), of course?
@ Demon, 07.12.2009 9:12:00
А уж работа с LaTeX+git - вообще сказка! Очень удобно работать над отдельными главами в отдельных ветках.
Так и в SVN я могу коммитить отдельно главы (рабочие каталоги).
@ Анонимный, 07.12.2009 10:24:00
Автор, открой для себя Git!
Я б с радостью...
@ Анонимный, 07.12.2009 11:41:00
А вот мне SVN как-то привычнее. В KDE хороший GUI, не напрягаюсь на предмет запоминания команд.
Кстати, про kdesvn можно тоже много чего сказать: весьма приятен и пользуюсь им довольно часто.
Буду благодарен уважаемым читателям за хинты с SVN. И просто конструктивную критику...
Внедрил SVN на работе - красота!
ОтветитьУдалитьТолько вот GUI(TortoiseSVN, увы только Винды здесь) немного глючит и пора заниматься обслуживанием репозитария - стирать удаленные бранчи.
Для git и mercurial усть Tortoise.
ОтветитьУдалитьШпагалка то что надо обязательно воспользуюсь может пригодится !! Некогда бы неподумал что можно использовать так свой блог...для подсказок самому себе :) Спасибо ...
ОтветитьУдалитьЯ использую этот блог очень часто именно как шпаргалку - за что Михаилу огромное спасибо. И именно поэтому мне не очень нравится новый стил оформления с облаком меток внизу - ведь приходится каждый раз проматывать вниз, чтобы найти нужные метки и статьи.
ОтветитьУдалитьЧто касается этой статьи, то
1) в разделе "Добавление новых файлов и каталогов в репозиторий Subversion" да и в других у меня примеры слились "в одну строку", что несколько затрудняет их понимание :) А результат вывода команды log и вовсе отфарматирован как иначе нежели остальные примеры статьи.
2) Пример со звездочкой в том виде, как он представлен здесь - скорее всего пройдет (у меня сходный пример прошел) - ведь "*", в данном случае резодвит shell и вместо нее подставятся нужных нам файлов:
ns@beggyHomeII:projects$ svn checkout file:///home/ns/work/data/repositories/Tmp
Checked out revision 0.
ns@beggyHomeII:projects$ cd Tmp/
ns@beggyHomeII:Tmp$ mkdir t_d t_s
ns@beggyHomeII:Tmp$ touch t_s/{1.jpg,2.txt,3.jpg}
ns@beggyHomeII:Tmp$ svn add t_d t_s
A t_d
A t_s
A t_s/2.txt
A t_s/1.jpg
A t_s/3.jpg
ns@beggyHomeII:Tmp$ svn commit ./* -m "init"
Adding t_d
Adding t_s
Adding t_s/1.jpg
Adding t_s/2.txt
Adding t_s/3.jpg
Transmitting file data ...
Committed revision 1.
ns@beggyHomeII:Tmp$ svn mv t_s/*jpg t_d/
A t_d/1.jpg
D t_s/1.jpg
A t_d/3.jpg
D t_s/3.jpg
ns@beggyHomeII:Tmp$ svn status
D t_s/1.jpg
D t_s/3.jpg
A + t_d/1.jpg
A + t_d/3.jpg
ns@beggyHomeII:Tmp$ svn commit -m "moved"
Adding t_d/1.jpg
Adding t_d/3.jpg
Deleting t_s/1.jpg
Deleting t_s/3.jpg
Committed revision 2.
ns@beggyHomeII:Tmp$ svn mv 't_d/*jpg' t_s/
svn: Path 't_d/*jpg' does not exist
ns@beggyHomeII:Tmp$ svn mv t_d/*jpg t_s/
A t_s/1.jpg
D t_d/1.jpg
A t_s/3.jpg
D t_d/3.jpg
ns@beggyHomeII:Tmp$ svn --version
svn, version 1.5.1 (r32289)
compiled Aug 6 2009, 16:55:38
Copyright (C) 2000-2008 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).
..........
Из этого примера видно, что использование "*" возможно в рамках shell-а и понимания происходящего. Но когда мы экранируем строку со "*" одинарными кавычками, т.е. действительно заставлем svn с ней работать, то subversion тут же "расстраивается"
Надеюсь, я ничего не напутал и не пропустил, в противном случае прошу меня извинить.
... и прошу прощения за огромное кол-во очепяток.
ОтветитьУдалитьа теперь так же про GIT
ОтветитьУдалитьНе уверен, что нужно говорить про GIT - статья про svn и Михаил уже объяснил почему именно про него.
ОтветитьУдалитьЯ бы еще добавил команду постановки метки (создания branch)- что-то вроде
svn copy svn://path/to/project/trunk svn://path/to/project/tags/labelName.
Can you suggest a good, working git GUI-based program? For Windows (C), of course?
ОтветитьУдалитьTortoiseGit
Переходите на DVCS. Без вариантов, это будущее (аскорее даже настоящее) контроля ревизий. Не важно что вы выберете: Git, Bazaar, Mercurial, у каждого из них есть свои сильные стороны. Предпочтение одного из них можно считать просто вопросом вкуса, учитывая, что они зачастую интероперабельны. Ну или станут таковыми в недалёком будущем.
ОтветитьУдалитьА Subversion просто морально устарел.
А что касается практического внедрения, то мне удалось обучить пользоваться на базовом уровне TortoiseGit даже нескольких дизайнеров.
@ Pavel пишет...
ОтветитьУдалитьТолько вот GUI(TortoiseSVN, увы только Винды здесь) немного глючит
Это можно пережить, главное - что он есть. И про винду да, это главное: тут у нас MS-рассадник.
@Сергей Любимов пишет...
Для git и mercurial усть Tortoise.
Не знал. А как работает под виндой? И желательно под маком тоже: к нам и макинтошевцы захаживают.
@ Neghen пишет...
Некогда бы неподумал что можно использовать так свой блог...для подсказок самому себе :)
Так в этом вся соль: пишешь для себя, т.е. максимально разжёвано, чтоб потом быстро вспомнить. Я очень часто собственные заметки перечитываю. Особенно поиском.
@ Beggy пишет...
Я использую этот блог очень часто именно как шпаргалку
Так и я тоже :-)
И именно поэтому мне не очень нравится новый стил оформления с облаком меток внизу - ведь приходится каждый раз проматывать вниз
Есть такой момент. Зато удобно читать: ничего по бокам не отвлекает.
1) в разделе "Добавление новых файлов и каталогов в репозиторий Subversion" да и в других у меня примеры слились
Иногда quotation неправильно обрабатывается - то ли Blogger, то ли Scribefire чудит. Бывает. Исправил. И статью обновил.
2) Пример со звездочкой в том виде, как он представлен здесь - скорее всего пройдет
А почему не должен пройти? Хотя да, пройдёт для bash. Для винды не знаю. Но это не моя епархия :-)
@ Beggy пишет...
и прошу прощения за огромное кол-во очепяток.
Да ладно :-) Пока редактор не видит - можно пошалить :-)
@ MORiKOFF пишет...
а теперь так же про GIT
Дык это... осваивать надо... :-)
@ Beggy пишет...
Не уверен, что нужно говорить про GIT
Надо-надо, а то Михаил в танке, а тут благодарные комментаторы отгрузили много ценных мыслей про git.
Я бы еще добавил команду постановки метки (создания branch)
Тут я должен сказать честно: я в идею меток не врубился. То есть, не понимаю, какой от этого профит (кроме геморроя при merge). И пока мне это не потребовалось. Если кто кинет хорошей ссылкой - буду крайне признателен.
@ Sveolon пишет...
TortoiseGit
Thanks a lot, mate! I'm going to google it and consider to use it.
@ uptimebox пишет...
Переходите на DVCS. Без вариантов
Дык ёлки-лампочки... Я что-ли на винде сижу!? Местный истеблишмент только докумекал до систем контроля версий (и то самые продвинутые), а тут переход... А бенефиты этого есть? Только без git rulez forever...
А Subversion просто морально устарел.
Для наших применений - с головой хватает. И даже больше.
мне удалось обучить пользоваться на базовом уровне TortoiseGit даже нескольких дизайнеров.
Буду иметь в виду TortoiseGit. Я про него не знал. Так что спасибо!
Ну в случае с метками (ветками) польза для текста, над которым работает в лучшем случае два-три человека наверное лишь в "этапах пути" - т.е. если вам нужно как-то обозначить некое состояние документа - например "статья в декабрьский номер журнала", "предварительная рыба" и тд. Не знаю есть ли у вас какие-нибудь этапы в жизни статей, книг, диссеров, так что может быть и не очень это нужно. Но если есть необходимость возвращаться к некому этапу, то лучше такие метки, чем номера ревизий
ОтветитьУдалить@virens
ОтветитьУдалитьв идею меток не врубился
"ссылками бросаться" не буду, а
коротко могу объяснить: мы пользуемся тагами/метками для "замораживания" последнего стабильного состояния проекта (релиза).
Сначала каждый разработчик отмечает стабильную и оттестированную версию своего компонета в ./tags/componentZ/versionA. Для релиза создается директория ./tags/projectP/release1 и в ней создаются таги==ссылки на все входящие в релиз компоненты (точнее на их метки/таги). Пока идет тестирование релиза и его внедрение, в ./trunc/ разработчики могут продолжать разработку новых версий или фиксить старые.
Т.е. метки очень удобны для быстрого доступа к проверенным состояниям большого количества компонентов.
Для личного использования планирую все /etc (и может /home) со всех домашних компов собрать на одном сервере и отмечать перед каждым upgrade, чтобы было проще котролировать изменения - я перевел все на Ubuntu 9.04 дома, а с ним удобно полуавтоматически обновлять.
Небольшой доп. комментарий:
ОтветитьУдалить= Зная номер SVN revision к любой версии любой директории или компонента можно обратится и без метки, но очень удобно иметь комментарий в виде метки :)
= при использовании меток в качестве общих комментариев, в настоящии комментарии (SVN log message) можно помещать более техническую информацию о сделанных изменениях, т.е. не надо лазить все время в исходники.
= метки по сути это hard link
= если нужно "обновить метку" - просто удаляется предудущая и создается новая - мы этим пользуемся часто
@virens
ОтветитьУдалитьofftopic: Спасибо за переход на новый формат блога - наконец-то могу комментировать из FF3 c работы.
На счет бенефитсов распределенных VCS: надобность была - отправляли ветку кода по email, получали обратно и мержили в обзий репозитарий.
ОтветитьУдалитьПотом Code Review - очень удобно - пиши себе на компе что хочешь - в общий репозитарий войдет то, что надо
По поводу систем контроля:
ОтветитьУдалитьначинал с гит, как говорится, ниасилил.
продолжал с меркуриалом. понравился простотой, короткими командами(в отличие от гита).
позже понадобился свн. почитал, поплевался, но пользоваться приходится.
центральный сервер это и + и - одновременно: ревизии синхронизируются между отдельными рабочими папками намного легче. чем синхронизировать репозитории в меркуриале. НО центральный сервер нужен даже для того, чтобы посмотреть историю. это никуда не годится.
В общем остановился на меркуриале(в примере с дипломной было бы, имхо, рациональнее использовать как раз его, ибо не всегда есть доступ к серверу если надо что-то быстро поправить и /сохранится/), тем более что есть нативный консольный интерфейс под винды, да и тортойз тоже радует гуями. советую.
@ Beggy, 09.12.2009 23:34:00
ОтветитьУдалитьнужно как-то обозначить некое состояние документа - например "статья в декабрьский номер журнала", "предварительная рыба" и тд. Не знаю есть ли у вас какие-нибудь этапы в жизни статей
А, я понял. Типа milestones. Этапы у статей у нас есть, но они сильно растянуты во времени. Тексты пишу я один.
Но если есть необходимость возвращаться к некому этапу, то лучше такие метки, чем номера ревизий
Понятно. Спасибо, попробую это внедрить.
@ Pavel, 10.12.2009 11:43:00
мы пользуемся тагами/метками для "замораживания" последнего стабильного состояния проекта (релиза).
Ясно. Со статьями несколько иначе: там "ползучие релизы", то есть релиз только один на самом деле - это когда всё готово и отправляем.
= метки по сути это hard link
Ага, аналогию ухватил.
offtopic: Спасибо за переход на новый формат блога - наконец-то могу комментировать из FF3 c работы.
А что, раньше всё так плохо было, да? :-)
@Анонимный, 11.12.2009 7:50:00
На счет бенефитсов распределенных VCS: надобность была - отправляли ветку кода по email, получали обратно и мержили в обзий репозитарий.
Кстати да, вот это очень ценная возможность.
Потом Code Review - очень удобно - пиши себе на компе что хочешь - в общий репозитарий войдет то, что надо
Туда же - это в самом деле очень круто. Иногда я отрезан от центрального репозитория (правлю что-нибудь в полевых условиях), и это очень неудобно. Git в этом плане, конечно, на коне.
@ A.I.D., 12.12.2009 17:22:00
позже понадобился свн. почитал, поплевался, но пользоваться приходится.
А я вот как раз с SVN и начинал. Ничего так, вроде нормально.
центральный сервер это и + и - одновременно
Согласен. На самом деле, единственная вещь, которая до меня сейчас не дошла - как синхронизировать все правки!? Вот у меня есть главный комп, есть ноут и нетбук. Боюсь, что с Git получится бардак - везде будут свои репы по проектам, но я перестану понимать, где последняя. В SVN это просто: где центральный репозиторий, там и счастье. Счастье кончается, когда оно начинает сшивать перекрывающиеся правки, но всё равно - я знаю, где HEAD.
НО центральный сервер нужен даже для того, чтобы посмотреть историю. это никуда не годится.
Да, это минус. Особенно, если он грохнется (у меня оно на переносном винчестере).
Я тут после комментариев к посту начал потихоньку GIT ковырять - уже один репозиторий сделал с нужными данными. Радуют локальные коммиты, но что-то меня клинит и я не врубаюсь в то, как собрать все правки в одном месте (да-да, я в курсе про push и pull, но хочется что-то типа центрального резервного хранилища).
Товарищам комментаторам в очередной раз спасибо - Git начинаю распробовать и, по крайней мере частично, постараюсь использовать.
@virens
ОтветитьУдалитьСо статьями несколько иначе: там "ползучие релизы", то есть релиз только один на самом деле
Тогда я не понимаю совершенно, зачем "городить огород"?
Для версий достаточно и CVS, а синхронизацию всех документов можно чем угодно сделать. Тем же DropBox или UbuntuOne. Мне кажется, что это и "более правильно" будет
Павел.
PS: Странный все-таки этот blogger.com: под виндами распознал регистрацию в Гугле, а под Ubuntu - нет...
> Вот у меня есть главный комп, есть ноут и нетбук. Боюсь, что с Git получится бардак - везде будут свои репы по проектам, но я перестану понимать, где последняя
ОтветитьУдалитьдля этого в git тоже можно сделать центральный репозитарий! git --bare рулит. если честно - я тоже долго вкуривал (целый день), но потом... летим птичка - там много вкусного ))
@ Анонимный, 12.12.2009 23:15:00
ОтветитьУдалитьТогда я не понимаю совершенно, зачем "городить огород"?
Объясняю: есть стационарный комп дома и в лаборатории, есть ноутбук и нетбук для творчества в полевых условиях, и есть эстетствующее начальство с коронной фразой "знаешь, а вот месяц назад там-то был такой забойный абзац - он бы вот сейчас очень к месту". Поэтому я не рву на себе волосы, а лезу в SVN репозиторий и достаю требуемое.
Для версий достаточно и CVS
Типун тебе, Павел, на язык: без атомарных коммитов мне VCS вообще не нужна.
@Анонимный, 20.12.2009 9:52:00
> Вот у меня есть главный комп, есть ноут и нетбук. Боюсь, что с Git получится бардак - везде будут свои репы по проектам, но я перестану понимать, где последняя
для этого в git тоже можно сделать центральный репозитарий!
Поздно, Дубровский, я замужем (с) классика. Хлебнув горя с этим .... git-ом и заценив работу команды git-push (какую траву косил Торвальдс!?), и будучи в полном шоке от распределённого бардака неконсистентных репов с кучей веток, я открыл для себя Mercurial. Слава роботам, кто-то ещё пишет программы для людей.
git --bare рулит.
Не рулит. Вообще. Никак. Начитавшись "документации" и форумов с криками "не используйте push, есть ведь pull" - мне такое не надо. Меркуриал потихоньку начал вытеснять мои SVNовские репы.
если честно - я тоже долго вкуривал (целый день),
Мне работать надо, а не вкуривать наркоманскую документацию. Так что увы.
летим птичка - там много вкусного ))
Может там и хорошо, но мне туда не надо :-) У меня скромные запросы, ваять новый юникс в ближайшее время не собираюсь, так что спасибо за предложение, но мне и на меркуриале неплохо.
> Не рулит. Вообще. Никак. Начитавшись "документации" и форумов с криками "не используйте push, есть ведь pull" - мне такое не надо. Меркуриал потихоньку начал вытеснять мои SVNовские репы.
ОтветитьУдалить>Мне работать надо, а не вкуривать наркоманскую документацию. Так что увы.
жжете. 1 день чтения доков при переходе на git - это проблема? а читать форумы я бы не советовал, ибо там таки же как Вы.
рад за mercurial - но мне git по душе пришелся сразу. впрочем вот пруфлинк
http://forum.ru-board.com/topic.cgi?forum=33&topic=9301
жжете. 1 день чтения доков при переходе на git - это проблема?
ОтветитьУдалитьДля меня - да, и большая. У меня вообще 1 выходной в неделю и на разборки с документацией мне его тратить не хочется.
а читать форумы я бы не советовал, ибо там таки же как Вы.
Это правда: там такие же, как я, которые думают, что git push передаст изменения из локального в репозитория в удалённый без плясок с бубном. Да, мы круто ошиблись...
Не суть. Комментарии навели меня на мысль об уходе с SVN на Меркуриал. С гитом пока не срослось. Но за ценные советы благодарен.
@virens
ОтветитьУдалитьТипун тебе, Павел, на язык: без атомарных коммитов мне VCS вообще не нужна.
Как скажете, Михаил :)
Мое дело - предложить самое простое (и, надеюсь, удобное) решение, "Нет" - так нет.
об уходе с SVN на Меркуриал
Будет пару часов - поиграюсь, но переводить весь отдел на новую source VCS без достаточно веских оснований и конкретных преимуществ - увольте.
> рад за mercurial - но мне git по душе пришелся сразу. впрочем вот пруфлинк
ОтветитьУдалитьhttp://forum.ru-board.com/topic.cgi?forum=33&topic=9301
Сходил, думал там нормальные обзоры.
Википедийные сравнения курят в стороне от такого "сравнения", неужели для кого-то такая ахинея может быть убедительным аргументом?
Для чайников появился мануал (правда на аглицком) Mercurial
ОтветитьУдалитьhttp://hginit.com/
svn log -v | grep spatialcoh -A 5 -B 5
ОтветитьУдалитьМне тут вчера показали хинт, вместо этого можно писать
svn log -v | grep spatialcoh -C 5
(Context)