Entry tags:
Firefox Multi-Account Containers
Полезное расширение, если есть несколько учетных записей на Github и т.п.
rcs, cvs, svn, mercurial, git...
В 1997 году я случайно в терминале FreeBSD набрал "ci" вместо "vi" и... это стало любовью на всю жизнь.
А вы как познакомились со своей первой системой контроля версий?
Что интересно, я до сих пор использую rcs, когда нужно всего пару файликов в каталоге поместить под контроль версий. hg или git в этом случае overkill.
git издевается надо мной
Есть git-репозиторий в Интернете и два его клона: первый на работе, второй дома. Workflow такой: поработал на работе, commit, push. Пришел домой, pull, поработал, commit, push.
Внимание вопрос. Когда я снова прихожу на работу и делаю pull, какого черта мне предлагается оформить этот pull как commit и ввести log message? В результате весь лог засорен этими бессмысленными коммитами с сообщениями "Merge branch 'master' of ssh..."
Вот Mercurial ведь так не делает! Когда я делаю pull на работе, он понимает, что отправленные из дома changesets уже есть в репозитории, не надо их описывать дважды! Надо просто тихо синхронизировать немного отставший локальный репозиторий с удаленным.
Может я чего-то не понимаю или ключик какой надо гиту указать?
Entry tags:
git дерьмо
Стандартная ситуация: основная работа идёт на машине A (рабочая копия и репозиторий - всё вместе). Сделал клон репозитория на машину B, чтобы там поработать. Поработал на B, покоммитил, хочу сделать push на машину A.
Mercurial: сделал push, изменения ушли наверх.
Git: хрен тебе:
Не нужен мне bare repository на машине A, там рабочая копия, в которой вся основная работа и идёт. Оказывается есть команда "git config receive.denyCurrentBranch updateInstead", которая в этом месте выпрямляет git и делает его похожим на hg. В вышеприведенном сообщении гита конечно про updateInstead ничего нет.
Mercurial: сделал push, изменения ушли наверх.
Git: хрен тебе:
remote: error: refusing to update checked out branch: refs/heads/master remote: error: By default, updating the current branch in a non-bare repository remote: is denied, because it will make the index and work tree inconsistent remote: with what you pushed, and will require 'git reset --hard' to match remote: the work tree to HEAD. remote: remote: You can set the 'receive.denyCurrentBranch' configuration variable remote: to 'ignore' or 'warn' in the remote repository to allow pushing into remote: its current branch; however, this is not recommended unless you remote: arranged to update its work tree to match what you pushed in some remote: other way. remote: remote: To squelch this message and still keep the default behaviour, set remote: 'receive.denyCurrentBranch' configuration variable to 'refuse'.
Не нужен мне bare repository на машине A, там рабочая копия, в которой вся основная работа и идёт. Оказывается есть команда "git config receive.denyCurrentBranch updateInstead", которая в этом месте выпрямляет git и делает его похожим на hg. В вышеприведенном сообщении гита конечно про updateInstead ничего нет.
Entry tags:
Перекодировка текстов в репозитории mercurial
Изначально мои репозитории с текстами создавались ещё в CVS и в кодировке KOI8-R. Потом были экспортированы в SVN и Mercurial, но кодировка текстов осталась KOI8-R.
Появилось желание перекодировать тексты в Unicode, вместе с их историей, как будто они изначально были в Unicode. В рассылке mercurial@mercurial-scm.org Steve Fink дал мне расширение к расширению convert, которое это позволяет.
Сработало прекрасно.
Появилось желание перекодировать тексты в Unicode, вместе с их историей, как будто они изначально были в Unicode. В рассылке mercurial@mercurial-scm.org Steve Fink дал мне расширение к расширению convert, которое это позволяет.
No promises, but you could give this a try: https://hg.sr.ht/~sfink/cmdconvert
Clone it to somewhere like ~/lib/hg. Add
[extensions]
cmdconvert = ~/lib/hg/cmdconvert
to your ~/.hgrc (or hgrc.ini or whatever it is on Windows.)
Then try running
hg convert --command 'iconv -f KOI8-R -t UTF-8' your_repo new_repo
Odds of it working on the first try are somewhat low (I don't really know what
I'm doing.)
If you want to restrict by file extension, do something like
hg convert --ext .txt --ext .html --command 'iconv -f KOI8-R -t UTF-8' your_repo
new_repo
It's not going to be fast, either.Сработало прекрасно.
Перенес свои публичные репозитории на Sourcehut.
Сабж: https://hg.sr.ht/~vas/
С Bitbucket со временем уберу, либо они сами исчезнут в связи с прекращением поддержки Mercurial. Обновлять на Bitbucket с этого момента уже ничего не буду.
PGP ключ, которым подписываются сообщения от sr.ht, лежит тут: https://meta.sr.ht/privacy/pubkey , отпечаток вроде как "447B 69E4 B34B E90B C829 A0E9 6597 04D1 A38A 93AE".
С Bitbucket со временем уберу, либо они сами исчезнут в связи с прекращением поддержки Mercurial. Обновлять на Bitbucket с этого момента уже ничего не буду.
PGP ключ, которым подписываются сообщения от sr.ht, лежит тут: https://meta.sr.ht/privacy/pubkey , отпечаток вроде как "447B 69E4 B34B E90B C829 A0E9 6597 04D1 A38A 93AE".
Entry tags:
Bitbucket прекращает поддержку Mercurial
https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket
Bitbucket прекращает поддержку Mercurial с июня будущего года. Это жаль по двум причинам, одна личная, другая глобальная.
1. У меня на https://bitbucket.org/victor_sudakov/ опубликован маленький репозиторий с текстами и конфигами, конвертировать его из mercurial в git я не хочу, потому что не люблю git. Придется искать какой-то хостинг репозиториев mercurial, и найду ли ещё такой удобный как Bitbucket - вопрос.
2. В IT мире почему-то часто побеждают какие-то кривые костыльные решения. IMHO git по сравнению с элегантным и продуманным mercurial - набор кривых хакерских костылей. И workflow в нём сложились уродские.
Надеюсь что сам mercurial как таковой не загнётся и будет продолжать меня радовать.
Bitbucket прекращает поддержку Mercurial с июня будущего года. Это жаль по двум причинам, одна личная, другая глобальная.
1. У меня на https://bitbucket.org/victor_sudakov/ опубликован маленький репозиторий с текстами и конфигами, конвертировать его из mercurial в git я не хочу, потому что не люблю git. Придется искать какой-то хостинг репозиториев mercurial, и найду ли ещё такой удобный как Bitbucket - вопрос.
2. В IT мире почему-то часто побеждают какие-то кривые костыльные решения. IMHO git по сравнению с элегантным и продуманным mercurial - набор кривых хакерских костылей. И workflow в нём сложились уродские.
Надеюсь что сам mercurial как таковой не загнётся и будет продолжать меня радовать.
DNS в VCS
В «NCSC Advisory on Ongoing DNS Hijacking Campaign» дается совет:
if operating your own DNS infrastructure, consider robust change control processes to manage any changes to your zone file. Ideally you should use a DNS zone file that is managed through a version control system, such as git. This will provide a backup of your DNS records, allow change-auditing and easy rollback. Enforce levels of organisational approval which is monitored before changes are made.
[...]
if you operate a critical domain, consider monitoring for domain transfers, WHOIS data changes, and nameserver changes.
А я ещё с 2000 года держал зоны tomsk.ru, tomsk.su и остальные в CVS, и мониторил изменения в базе RIPN, посылая каждые 2 часа whois-запрос и сравнивая с результатом last known good запроса.
Я молодец?
if operating your own DNS infrastructure, consider robust change control processes to manage any changes to your zone file. Ideally you should use a DNS zone file that is managed through a version control system, such as git. This will provide a backup of your DNS records, allow change-auditing and easy rollback. Enforce levels of organisational approval which is monitored before changes are made.
[...]
if you operate a critical domain, consider monitoring for domain transfers, WHOIS data changes, and nameserver changes.
А я ещё с 2000 года держал зоны tomsk.ru, tomsk.su и остальные в CVS, и мониторил изменения в базе RIPN, посылая каждые 2 часа whois-запрос и сравнивая с результатом last known good запроса.
Я молодец?
Entry tags:
VCS пошли куда-то не туда
Я более 20 лет использую системы контроля версий, начинал ещё с RCS, сейчас такую наверное и не помнят. Но вот это для меня звучит полной тарабарщиной:
Squashing commits via the command line using "git merge - squash" is just another time consuming step. That's why we have an option to allow Git users to automatically squash commits in feature branches when merging pull requests. This helps you maintain a clean, easy-to-follow history for your repo.
Такое впечатление, что история изменений вместо своей изначальной задачи - сохранения всех изменений, чтобы ничего не пропало, стала самоцелью, средством публикации красивых патчей.
Историей изменений безжалостно манипулируют, перелопачивают, сливают и удаляют changeset-ы, целые ветки пересаживают с места на место в дереве - к чему всё это? Следы запутать? Это тот самый формализм, когда форма становится важнее содержания.
Squashing commits via the command line using "git merge - squash" is just another time consuming step. That's why we have an option to allow Git users to automatically squash commits in feature branches when merging pull requests. This helps you maintain a clean, easy-to-follow history for your repo.
Такое впечатление, что история изменений вместо своей изначальной задачи - сохранения всех изменений, чтобы ничего не пропало, стала самоцелью, средством публикации красивых патчей.
Историей изменений безжалостно манипулируют, перелопачивают, сливают и удаляют changeset-ы, целые ветки пересаживают с места на место в дереве - к чему всё это? Следы запутать? Это тот самый формализм, когда форма становится важнее содержания.
Entry tags:
textproc/colordiff
Открыл для себя textproc/colordiff. Как же мне его не хватало все эти годы в CVS и SVN!
В mercurial есть встроенное расширение color:
В mercurial есть встроенное расширение color:
[extensions] color = pager = [pager] pager = LESS='FRXj4' less
husky again
Проект Husky портирован с https://sourceforge.net/projects/husky/ на https://github.com/huskyproject
From: Michael Dukelsky 2:5020/1042
Поскольку на sf.net перестали поддерживать CVS и вообще sf.net показал себя ненадёжной. организацией, Husky теперь живёт в Git, а не в CVS и на гитхабе, а не на сорсфорже. Перенесены все подпроекты, кроме hflist, mail2pkt и pkt2mail: эти три подпроекта фактически уже были удалены и лежали пустыми.
Теперь немного технических деталей. Я положил каждый подпроект в отдельный репозиторий. Можно было вместо этого использовать подмодули (submodules) или поддеревья (subtrees). Подмодули легко устанавливаются, однако их использование содержит много граблей, на которые очень просто наступить, и об этом много написано в интернете. С поддеревьями всё хорошо, пока в поддереве только одна ветка master. С несколькими ветками всё становится сложней. Поэтому я выбрал вариант отдельного репозитория для каждого подпроекта. Однако, если будут серьёзные возражения, то можно сделать и по-другому. Конвертирование cvs->git сделано с помощью cvs2git (содержится в проекте cvs2svn). При этом я не делал никаких тонких настроек, чтобы улучшить перевод веток cvs в ветки git. Проблема там заключается в том, что cvs не делает особой разницы между метками и ветками, и один и тот же идентификатор может быть в одном месте меткой, а в другом - веткой. К тому же, в Husky бардак и, например, ветки areastat-1_4-stable и husky-1_4-stable в подпроекте areastat не совпадают. Все предложения по улучшению конвертации будут с благодарностью приняты.
Прошу всех разработчиков прислать мне своё имя на гитхабе, чтобы я мог добавить вас в huskyproject.
From: Michael Dukelsky 2:5020/1042
Поскольку на sf.net перестали поддерживать CVS и вообще sf.net показал себя ненадёжной. организацией, Husky теперь живёт в Git, а не в CVS и на гитхабе, а не на сорсфорже. Перенесены все подпроекты, кроме hflist, mail2pkt и pkt2mail: эти три подпроекта фактически уже были удалены и лежали пустыми.
Теперь немного технических деталей. Я положил каждый подпроект в отдельный репозиторий. Можно было вместо этого использовать подмодули (submodules) или поддеревья (subtrees). Подмодули легко устанавливаются, однако их использование содержит много граблей, на которые очень просто наступить, и об этом много написано в интернете. С поддеревьями всё хорошо, пока в поддереве только одна ветка master. С несколькими ветками всё становится сложней. Поэтому я выбрал вариант отдельного репозитория для каждого подпроекта. Однако, если будут серьёзные возражения, то можно сделать и по-другому. Конвертирование cvs->git сделано с помощью cvs2git (содержится в проекте cvs2svn). При этом я не делал никаких тонких настроек, чтобы улучшить перевод веток cvs в ветки git. Проблема там заключается в том, что cvs не делает особой разницы между метками и ветками, и один и тот же идентификатор может быть в одном месте меткой, а в другом - веткой. К тому же, в Husky бардак и, например, ветки areastat-1_4-stable и husky-1_4-stable в подпроекте areastat не совпадают. Все предложения по улучшению конвертации будут с благодарностью приняты.
Прошу всех разработчиков прислать мне своё имя на гитхабе, чтобы я мог добавить вас в huskyproject.
Архив vs бэкап
Даже некоторые админы не понимают принципиального отличия архива (возможность отката данных на какое-то предыдущее состояние) от бэкапа (резервного копирования на случай отказа железа или софта). Вот история с башорга, которая эту разницу прекрасно иллюстрирует: http://bash.im/quote/446116
Между прочим, с распространением файловых систем, поддерживающих снапшоты (ZFS, NTFS), архив стал очень дешев. Роль архива способна выполнять и VCS.
А полноценный бэкап (особенно off site) по-прежнему дорог. А который с приемлемой скоростью восстановления - бешено дорог.
Между прочим, с распространением файловых систем, поддерживающих снапшоты (ZFS, NTFS), архив стал очень дешев. Роль архива способна выполнять и VCS.
А полноценный бэкап (особенно off site) по-прежнему дорог. А который с приемлемой скоростью восстановления - бешено дорог.
Entry tags:
- bug,
- questions,
- unix,
- vcs,
- копилка опыта
конвертация cvs в hg (solved)
Как сделать сабж таким образом, чтобы коммит-логи (в кодировке koi8-r) нормально перенеслись в hg? Возможно что-то надо написать в .hgrc, но что именно?
Гугление не очень помогло. Есть намеки, что cvsps можно пропустить через pipe, но не понял как.
UPD
Пришлось перекодировать весь CVS репозиторий в UTF-8, выставить локале ru_RU.UTF-8 и после этого уже запускать "hg convert". А потом перекодировать файлы в рабочей копии обратно в KOI8-R и коммитить это как изменение.
UPD2
https://bz.mercurial-scm.org/show_bug.cgi?id=5597
UPD2
Один японец написал hook, который проблему решает: https://bitbucket.org/foozy/hghook-cvslog-transcoder/overview Я проверил - работает.
Гугление не очень помогло. Есть намеки, что cvsps можно пропустить через pipe, но не понял как.
UPD
Пришлось перекодировать весь CVS репозиторий в UTF-8, выставить локале ru_RU.UTF-8 и после этого уже запускать "hg convert". А потом перекодировать файлы в рабочей копии обратно в KOI8-R и коммитить это как изменение.
UPD2
https://bz.mercurial-scm.org/show_bug.cgi?id=5597
UPD2
Один японец написал hook, который проблему решает: https://bitbucket.org/foozy/hghook-cvslog-transcoder/overview Я проверил - работает.
Entry tags:
husky
Pavel Gulchouck 2:463/68 выложил сабж на github:
Все модули проекта конвертнул и выложил на github (с историей и ветками): https://github.com/pgul/husky Решил не объединять их все в один репозиторий, а сделать сабмодулями. Впрочем, объединить всегда можно, если это покажется удобным. История при этом не потеряется, но ветки и тэги в этом случае будут. относиться ко всему проекту husky - собственно, из-за этого я и не стал их объединить. Получить всё можно так:
git clone git@github.com:pgul/husky.git
cd husky
git submodule update --init --recursive
Потом обновлять можно командой
git pull --recurse-submodules
Все модули проекта конвертнул и выложил на github (с историей и ветками): https://github.com/pgul/husky Решил не объединять их все в один репозиторий, а сделать сабмодулями. Впрочем, объединить всегда можно, если это покажется удобным. История при этом не потеряется, но ветки и тэги в этом случае будут. относиться ко всему проекту husky - собственно, из-за этого я и не стал их объединить. Получить всё можно так:
git clone git@github.com:pgul/husky.git
cd husky
git submodule update --init --recursive
Потом обновлять можно командой
git pull --recurse-submodules
Entry tags:
Скопировать CVS-репозиторий с sourceforge.net
rsync -av husky.cvs.sourceforge.net::cvsroot/husky/ husky/
Началась какая-то поспешная кампания по переносу husky под git. Насколько я понял, репозиторий сконвертировали без сохранения истории, с выкидыванием части модулей... Лучше я сохраню себе локально на ноду то, что есть в CVS на husky.sourceforge.net, чтобы потом локти не кусать.
Началась какая-то поспешная кампания по переносу husky под git. Насколько я понял, репозиторий сконвертировали без сохранения истории, с выкидыванием части модулей... Лучше я сохраню себе локально на ноду то, что есть в CVS на husky.sourceforge.net, чтобы потом локти не кусать.
Entry tags:
Частичный перенос SVN репозитория
$ svnadmin dump repos/test1 |\
svndumpfilter --drop-empty-revs \
include /path/to/file1.txt /path/to/file2.txt > test1.svn
$ svnadmin create test2
$ svn mkdir --parents file://$PWD/test2/path/to
$ svnadmin load test2 < test1.svn
Без "svn mkdir" при импорте возникнет ошибка:
<<< Started new transaction, based on original revision 540
* editing path : path/to/file1.txt ...svnadmin: E160013:
* File not found: transaction '0-0', path
* '/path/to/file2.txt'
Entry tags:
Культура работы с текстовыми документами
У программистов очень развита культура работы с текстом. Патчи, диффы, системы контроля версий. Публикация патчей, перенос изменений из ветки в ветку или в другой проект, хранение и просмотр истории изменений, разрешение конфликтов - для всего этого придуманы инструменты.
А вот в мире бюрократов таких инструментов нет. Если в одном документе было изменено название организации или должность руководителя - применение этого изменения на десяток аналогичных документов превращается в утомительную ручную работу, в лучшем случае через контекстный поиск и замену, но придется открыть каждый документ.
В Microsoft Word встроена система контроля версий и даже есть нечто вроде visual diff, можно сливать документы, выбирая, какие отличия ты принимаешь, а какие отклоняешь. Но какой процент конторских работников об этой возможности знает? И получив от контрагента договор с правками, будет сличать свой и исправленный вариант не глазами, рискуя просмотреть подвох, а инструментами "Сравнить" и "Объединить"?
В Excel всё гораздо хуже. В нём даже нет элементарного аналога diff. А как полезно было бы иметь возможность сравнить таблицы и выделить отличающиеся ячейки, к примеру, цветом?
Если есть офисные пакеты, в которых есть искомое, или я просмотрел diff в составе Excel - дайте знать!
А вот в мире бюрократов таких инструментов нет. Если в одном документе было изменено название организации или должность руководителя - применение этого изменения на десяток аналогичных документов превращается в утомительную ручную работу, в лучшем случае через контекстный поиск и замену, но придется открыть каждый документ.
В Microsoft Word встроена система контроля версий и даже есть нечто вроде visual diff, можно сливать документы, выбирая, какие отличия ты принимаешь, а какие отклоняешь. Но какой процент конторских работников об этой возможности знает? И получив от контрагента договор с правками, будет сличать свой и исправленный вариант не глазами, рискуя просмотреть подвох, а инструментами "Сравнить" и "Объединить"?
В Excel всё гораздо хуже. В нём даже нет элементарного аналога diff. А как полезно было бы иметь возможность сравнить таблицы и выделить отличающиеся ячейки, к примеру, цветом?
Если есть офисные пакеты, в которых есть искомое, или я просмотрел diff в составе Excel - дайте знать!
Entry tags:
Entry tags:
prefs.js выложил
prefs.js со своими настройками выложил на https://bitbucket.org/victor_sudakov/configs/src
UPD теперь это https://hg.sr.ht/~vas/configs/browse/default/user.js
UPD теперь это https://hg.sr.ht/~vas/configs/browse/default/user.js