Небольшая шпаргалка по командам SVN

В этом посте я решил собрать простые и наиболее часто используемые мной команды svn, часть параметров и способов работы с репозиториями svn, которых я склонен забывать. Это своеобразная шпаргалка, описание subversion на простых примерах. Чтобы теперь находки по работе в subversion никуда не потерялись - им место в блоге.

По ходу действия хочу подчеркнуть, что 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
biblio/my.bib
U
biblio/my.bib.bak

Updated to revision 9.

Это обновит вашу локальную копию до ревизии, которая находится в репозитории SVN. После этого можно приступать к работе с файлами, так как они обновлены до последней версии.

Латинские буквы перед именем файла имеют свой сакральный смысл, скрытый в недрах документации сокрушительных размеров (кстати, документация очень хороша, и есть даже частичный перевод на русский тут). Собственно, буква означает действие, которое выполнил Subversion для приведения рабочей копии в актуальное состояние:
U foo

Updated — Файл foo был обновлен


A foo

Added — Файл или директория foo были добавлены в рабочую копию.


D foo

Deleted — Файл или директория foo были удалены из рабочей копии.


R foo

Replaced — Файл или директория foo была заменена в рабочей копии; это значит, что foo был удален, а новый элемент с таким же именем был добавлен.


G foo

merGed — Файл foo получил новые изменения из хранилища, однако ваша локальная копия содержит ваши
изменения. Либо изменения не пересекаются, либо они точно такие же, как ваши локальные изменения, поэтому Subversion успешно выполнил слияние изменений хранилища с файлом.


C foo

Conflicting — Файл 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
Reverted 'UMNIK08-Report-01/Report-01-sub1-shortened.tex'
После этого SVN вернёт файл 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
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
Красным подчеркнул я: видно, что файл
spatialcoherencyexplained.eps удалён в правку 436, и теперь хотим его восстановить. Смотрим, в какой правке файл был удалён - в 436, значит, в 435 есть его последняя копия. Восстанавливаем:
svn copy --revision 435 file:///phdthesis/images-opticalcoding/spatialcoherencyexplained.eps spatialcoherencyexplained.eps
Всё, теперь файл появится снова, вместе с историей правок (что важно) и вы можете его править дальше.

Ссылки
Разумеется, это далеко не все возможности Subversion - в данном посте не рассмотрены возможности создания и слияния веток, но в качестве быстрого введения должно хватить. Больше есть в переведённом на русский исчерпывающем мануале тут.

33 комментариев: |высказаться!| RSS-лента дискуссии.|
Анонимный комментирует...

Пересел с SVN на Git, не жалею... Из плюсов - распределенность, не нужен постоянно онлайн сервер, только одна папка .git в корне проекта, а не в каждой папке как .svn, прозрачная работа с тэгами и ветками
рекомендую

Desaider комментирует...

полностью с Анонимом согласен нужно прогрессировать...

http://total-sentences.blogspot.com/

Анонимный комментирует...

++

Use Git, Lik and force will be with you.

Demon комментирует...

А уж работа с LaTeX+git - вообще сказка! Очень удобно работать над отдельными главами в отдельных ветках.

Анонимный комментирует...

Автор, открой для себя Git!

Анонимный комментирует...

А вот мне SVN как-то привычнее. В KDE хороший GUI, не напрягаюсь на предмет запоминания команд.

virens комментирует...

@ Анонимный, 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. И просто конструктивную критику...

Pavel комментирует...

Внедрил SVN на работе - красота!
Только вот GUI(TortoiseSVN, увы только Винды здесь) немного глючит и пора заниматься обслуживанием репозитария - стирать удаленные бранчи.

Сергей Любимов комментирует...

Для git и mercurial усть Tortoise.

Neghen комментирует...

Шпагалка то что надо обязательно воспользуюсь может пригодится !! Некогда бы неподумал что можно использовать так свой блог...для подсказок самому себе :) Спасибо ...

Beggy комментирует...

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

Что касается этой статьи, то
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 тут же "расстраивается"
Надеюсь, я ничего не напутал и не пропустил, в противном случае прошу меня извинить.

Beggy комментирует...

... и прошу прощения за огромное кол-во очепяток.

MORiKOFF комментирует...

а теперь так же про GIT

Beggy комментирует...

Не уверен, что нужно говорить про GIT - статья про svn и Михаил уже объяснил почему именно про него.
Я бы еще добавил команду постановки метки (создания branch)- что-то вроде
svn copy svn://path/to/project/trunk svn://path/to/project/tags/labelName.

Sveolon комментирует...

Can you suggest a good, working git GUI-based program? For Windows (C), of course?


TortoiseGit

uptimebox комментирует...

Переходите на DVCS. Без вариантов, это будущее (аскорее даже настоящее) контроля ревизий. Не важно что вы выберете: Git, Bazaar, Mercurial, у каждого из них есть свои сильные стороны. Предпочтение одного из них можно считать просто вопросом вкуса, учитывая, что они зачастую интероперабельны. Ну или станут таковыми в недалёком будущем.

А Subversion просто морально устарел.

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

virens комментирует...

@ 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. Я про него не знал. Так что спасибо!

Beggy комментирует...

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

Pavel комментирует...

@virens
в идею меток не врубился
"ссылками бросаться" не буду, а
коротко могу объяснить: мы пользуемся тагами/метками для "замораживания" последнего стабильного состояния проекта (релиза).
Сначала каждый разработчик отмечает стабильную и оттестированную версию своего компонета в ./tags/componentZ/versionA. Для релиза создается директория ./tags/projectP/release1 и в ней создаются таги==ссылки на все входящие в релиз компоненты (точнее на их метки/таги). Пока идет тестирование релиза и его внедрение, в ./trunc/ разработчики могут продолжать разработку новых версий или фиксить старые.

Т.е. метки очень удобны для быстрого доступа к проверенным состояниям большого количества компонентов.

Для личного использования планирую все /etc (и может /home) со всех домашних компов собрать на одном сервере и отмечать перед каждым upgrade, чтобы было проще котролировать изменения - я перевел все на Ubuntu 9.04 дома, а с ним удобно полуавтоматически обновлять.

Pavel комментирует...

Небольшой доп. комментарий:

= Зная номер SVN revision к любой версии любой директории или компонента можно обратится и без метки, но очень удобно иметь комментарий в виде метки :)

= при использовании меток в качестве общих комментариев, в настоящии комментарии (SVN log message) можно помещать более техническую информацию о сделанных изменениях, т.е. не надо лазить все время в исходники.

= метки по сути это hard link

= если нужно "обновить метку" - просто удаляется предудущая и создается новая - мы этим пользуемся часто

Pavel комментирует...

@virens
offtopic: Спасибо за переход на новый формат блога - наконец-то могу комментировать из FF3 c работы.

Анонимный комментирует...

На счет бенефитсов распределенных VCS: надобность была - отправляли ветку кода по email, получали обратно и мержили в обзий репозитарий.

Потом Code Review - очень удобно - пиши себе на компе что хочешь - в общий репозитарий войдет то, что надо

A.I.D. комментирует...

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

virens комментирует...

@ 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 рулит. если честно - я тоже долго вкуривал (целый день), но потом... летим птичка - там много вкусного ))

virens комментирует...

@ Анонимный, 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

virens комментирует...

жжете. 1 день чтения доков при переходе на git - это проблема?
Для меня - да, и большая. У меня вообще 1 выходной в неделю и на разборки с документацией мне его тратить не хочется.

а читать форумы я бы не советовал, ибо там таки же как Вы.
Это правда: там такие же, как я, которые думают, что git push передаст изменения из локального в репозитория в удалённый без плясок с бубном. Да, мы круто ошиблись...

Не суть. Комментарии навели меня на мысль об уходе с SVN на Меркуриал. С гитом пока не срослось. Но за ценные советы благодарен.

Pavel комментирует...

@virens
Типун тебе, Павел, на язык: без атомарных коммитов мне VCS вообще не нужна.

Как скажете, Михаил :)
Мое дело - предложить самое простое (и, надеюсь, удобное) решение, "Нет" - так нет.

об уходе с SVN на Меркуриал

Будет пару часов - поиграюсь, но переводить весь отдел на новую source VCS без достаточно веских оснований и конкретных преимуществ - увольте.

Анонимный комментирует...

> рад за mercurial - но мне git по душе пришелся сразу. впрочем вот пруфлинк
http://forum.ru-board.com/topic.cgi?forum=33&topic=9301
Сходил, думал там нормальные обзоры.
Википедийные сравнения курят в стороне от такого "сравнения", неужели для кого-то такая ахинея может быть убедительным аргументом?

Анонимный комментирует...

Для чайников появился мануал (правда на аглицком) Mercurial

http://hginit.com/

triklozoid комментирует...

svn log -v | grep spatialcoh -A 5 -B 5

Мне тут вчера показали хинт, вместо этого можно писать
svn log -v | grep spatialcoh -C 5

(Context)

Отправить комментарий

Подписаться на RSS-ленту комментариев к этому посту.