![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cranequinierЭто пост для программистов. Вдруг кто чего подскажет.
Делаю новый репозиторий для глубоко приватных C++-ных исходников. Собираюсь его бесплатно хостить на Bitbucket, и доступаться к нему из пары-тройки мест на планете через SourceTree. Выбираю между Git и Mercurial. И вот меня скрутило - исходники, люди и процессы такие, что надо сохранять дату файлов на диске, хоть ты тресни. А оне оба - и Git и Mercurial - по-умолчанию ставят дату последнего слива с сервера. При этом Mercurial довольно просто фиксится примочкой TimestampMod Extension, и начинает даты файлов уважеть, а Git если и фиксится вообще, то как-то через задницукак и всё в Git. Поэтому я слегка скрипя сердцем склоняюсь к Mercurial, хотя знаю его похуже и вообще он какой-то умирающий.
Может я какую-то фигню делаю, а надо хостить где-то ещё, на своём хостинге, использовать SVNи переходить на Жабу? Вправьте мне скорее мозги... Ну чего вообще интересного есть в мире code hosting-а...
P.S. Мечта, конечно, fossil, но его считай что нету.
Делаю новый репозиторий для глубоко приватных C++-ных исходников. Собираюсь его бесплатно хостить на Bitbucket, и доступаться к нему из пары-тройки мест на планете через SourceTree. Выбираю между Git и Mercurial. И вот меня скрутило - исходники, люди и процессы такие, что надо сохранять дату файлов на диске, хоть ты тресни. А оне оба - и Git и Mercurial - по-умолчанию ставят дату последнего слива с сервера. При этом Mercurial довольно просто фиксится примочкой TimestampMod Extension, и начинает даты файлов уважеть, а Git если и фиксится вообще, то как-то через задницу
Может я какую-то фигню делаю, а надо хостить где-то ещё, на своём хостинге, использовать SVN
P.S. Мечта, конечно, fossil, но его считай что нету.
no subject
Date: 2015-02-12 04:59 am (UTC)А зачем?
У меня TortoiseSVN выставляет дату скачивания файла из репозитория (но не меняет дату, если скачивать файл не надо).
no subject
Date: 2015-02-12 05:46 am (UTC)Я имею ввиду что если файл модифицирован в 2005-м году, то в репозитории хранится его дата модификации, и на новой машине он будет датирован 2005-м годом, а не датой пулла или коммита.
> У меня TortoiseSVN выставляет дату скачивания файла из репозитория
Таким образом если ты залил в SVN проект, живший до этого сколько-то лет, у тебя вся история проекта до заливки полностью потеряна.
no subject
Date: 2015-02-12 07:54 am (UTC)А где у тебя до этого "жила история", я извиняюсь? Истории то не было? Даты файлов - это не история, а херня какая-то, они и восстановление из бэкапа не переживают зачастую.
С гитом вот у меня обратная проблема, оно ставит дату коммита такую, какая стоит на локальной машине, где коммит. На одной моей локальной виртуальной девелоперской машине херово идут часики (пока она suspended), в результате типичные даты коммитов там - отстают, бывает смешно.
Надо вот ntpdate по крону там запускать, который год собираюсь.
Соответственно, эту особенность можно попробовать использовать для этой самой твоей "истории", написав скрипт такого плана
- отсортировать файлы по дате "истории"
- охерачить вот таким мегаскриптом:
for file in filelist ; do
set computer-date-to; git add $file; git commit -a -m "$file added"
end
no subject
Date: 2015-02-12 07:55 am (UTC)Но на это, как раз, насрать, потому что тебя в качестве "истории" интересуют даты коммитов (и, да, хорошо бы на сервере проверять, что дата не в прошлом, это наверное делается хуком) и git log file
no subject
Date: 2015-02-12 04:01 pm (UTC)На это - безусловно.
Собственно есть простой путь - на каждой машине в директорию гитового репозитория разворачивается .zip архив со всеми датами файлов. Поскольку гит смотрит только хэши, а с ~~последней версии не портит существующие даты пуллом, всё как бы становится сравнительно хорошо, можно дальше работать.
Но как-то это совсем уж на соплях - в репозитории старых дат не ни в какой форме.
no subject
Date: 2015-02-12 05:53 pm (UTC)В репозитории должна быть история. Чтобы git diff или там git blame работал.
Без истории - нельзя.
no subject
Date: 2015-02-12 06:12 pm (UTC)no subject
Date: 2015-02-12 06:19 pm (UTC)no subject
Date: 2015-02-12 06:25 pm (UTC)no subject
Date: 2015-02-12 06:40 pm (UTC)upd: и git log, естественно.
no subject
Date: 2015-02-12 06:54 pm (UTC)no subject
Date: 2015-02-12 06:58 pm (UTC)no subject
Date: 2015-02-12 03:42 pm (UTC)В сериальных .zip-ах. А так же .tar.gz-ах.
> Истории то не было?
История была, просто её было трудоёмко смотреть. Но можно, и смотрели когда надо. А заливка в git её сносит начисто ващще.
> Даты файлов - это не история, а херня какая-то
Когда больше ничего нет даты вайлов это дико круто.
> они и восстановление из бэкапа не переживают зачастую.
Ну разве что из продвинутого линуксного бэкапа. Из моих бэкапов я регулярно поднимаю файлы с датами типа 1989-й год, второе марта.
> эту особенность можно попробовать использовать для этой самой твоей "истории", написав скрипт такого плана
Я понимаю, что можно написать. Но сам писать не хочу, ишь. Вон для hg оно уже написано довольно чисто и работает.
Может найду ещё для git-а нормальный готовый скрипт, что-то я такое читал.
А мечта, конечно - скрипту скормить миллион "коммитов" в архивах, и чтоб он создал историю в репозитории за далекое прошлое.
no subject
Date: 2015-02-12 05:52 pm (UTC)С ума сойти. В смысле, вот ты в 1998-м году (не говоря о 2005-м) вот несколько раз на дню зиповал все в архив его откладывал в сторонку?
И не имел возможности удобно посмотреть, когда (и кто - если ты был не один) написал эту строчку и почему?
А как так жить то можно?
>> Я понимаю, что можно написать. Но сам писать не хочу, ишь
Оказывается, у гита есть параметр --date к коммиту.
То есть все вообще просто, вот я пишу тебе скрипт который из твоих сериальных архивов все ухерачит:
for arc in `ls /path/to/archives/`; do
date=`хитрая механика по восстановлению даты из имени файла, раз нет другого, наверное sed справится`
unzip $arc
git add `find . -type f` # это добавит все новые файлы
git commit -a --date=$date -m "$date commited"
end
no subject
Date: 2015-02-12 05:57 pm (UTC)no subject
Date: 2015-02-12 06:23 pm (UTC)Даже в крупных корпорациях специально обученые люди при переходе с VCS на VCS обычно на историю забивают. Наверное и я подумаю недельку и-таки забью.
no subject
Date: 2015-02-12 06:39 pm (UTC)Я делал миграцию из CVS в SVN и из SVN в git своих личных репозиториев. Без проблем. Типа, за день.
Я делал миграцию *и модификацию системы сборки* в нашей мелкой компании (человек 30 разработчиков наверное) - упражнение на неделю где-то, но основная загвоздка была именно в том, что у нас система сборки сама брала из репозитория и сама собирала, а организация тегов в CVS и SVN разная.
То есть это задача такая вполне подъемная и необходимая.
no subject
Date: 2015-02-12 06:21 pm (UTC)Да я его и сейчас каждый день то тут то там несколько раз на дню зипую. Точнее конкретно сейчас 7z-плю - 7z победил на соревновании diff-ующих архиваторов сколько-то лет назад.
Я работаю за зарплату в лидирующем в некоторой области американском производителе софтвера. Если б я пять раз в день не архивировался, раза три-четыре в год исходники за пару дней точно бы грохались.
> И не имел возможности удобно посмотреть, когда (и кто - если ты был не один) написал эту строчку и почему?
Ну давай проведем эксперимент: достань свои исходники 1995-го года и посмотри кто и когда менял какие строчки. И расскажи насколько удобно это получилось.
Я вот пошел и достал, заняло примерно две минуты - 1994-й год, чтоб с запасом. За строчку не скажу, а даты модификации файлов вижу.
> То есть все вообще просто, вот я пишу тебе скрипт который из твоих сериальных архивов все ухерачит:
Это ж не скрипт, это ж только зародыш.
Понятно, что полный скрипт тоже можно написать, но это минимум пять часов работы, скорее десять.
no subject
Date: 2015-02-12 06:37 pm (UTC)Вместе с репозиторием? Понимаю!
>> Ну давай проведем эксперимент: достань свои исходники 1995-го года и посмотри кто и когда менял какие строчки. И расскажи насколько удобно это получилось.
95-го не могу, самый старый проект, формально доживший до наших дней - с 97-го года. Я его, правда, закрыл лет 10 как, поэтому он так и остался в CVS, через миграцию CVS-SVN-git не прошел.
Вот сделал cvs checkout, cvs annotate все показывает
===
$ cvs annotate ./src/modules/extra/mod_charset.c | head
....
1.4 (atmail 15-Oct-00): CMDCONST char *
1.4 (atmail 15-Oct-00): add_charset_recode_table(cmd_parms *cmd, charset_dir_t *dc, const char *arg)
1.4 (atmail 15-Oct-00): {
1.4 (atmail 15-Oct-00): char *cset1,*cset2,*table1_2, *table2_1;
...
===
Вот 15 октября нулевого года добавились эти строчки и я даже знаю кем.
>> Понятно, что полный скрипт тоже можно написать, но это минимум пять часов работы, скорее десять.
Да, скорее всего упражнение на день. Но с учетом того, что история всей жизни будет в человеческом, легко клонируемом и все такое формате - почему нет.
no subject
Date: 2015-02-12 06:52 pm (UTC)>Вместе с репозиторием? Понимаю!
Скорее даже не с репозиторием, а с каким-нибудь кривым merge-м. Который сделает в штате Коннектикут человек, которого я никогда не видел. Или ещё с какой фигнёй. Вот например у меня несколько моих собственных файлов в фирменом репозитории, которые кроме меня никто никогда наверное не трогал, имеют битые не-юниксные и не-видовзные CRLF-ы. Например одни CR-ы - и это ещё лёгкий случай.
Когда я первый раз ставил Git клиент в Windows, и увидел что он по-умолчанию хочет делать автоматическую трансляцию CRLF-ов туда-сюда, я только чудом ограничил свою вокализацию непонятными окрестным англосаксам чисто русскими словами...
> 95-го не могу, самый старый проект, формально доживший до наших дней - с 97-го года.
Если ты не можешь достать из рукава исходник старше 15 лет - значит половина твоей истории уже исчезла. А моей - не исчезла. Потому что она в zip-ах.
> Но с учетом того, что история всей жизни будет в человеческом, легко клонируемом и все такое формате - почему нет.
Определенный соблазн конечно есть. Git теперь надолго, и из него гарантированно можно будет экспортироваться в чего будет потом. Создать монументальную историю своих исходников, причем вообще всех...
no subject
Date: 2015-02-12 07:04 pm (UTC)Вот с 97-го могу достать из репозитория. С 93-го могу из тех самых зипов.
87-90-й годы точно пропали (оно было на дискетах, я на них посмотрел и выкинул нахер).
91-92 - пропали скорее всего (надо смотреть в ящике с сидюками).
>> Скорее даже не с репозиторием, а с каким-нибудь кривым merge-м
Не, не понимаю. Твой то коммит останется.
no subject
Date: 2015-02-12 07:10 pm (UTC)>Не, не понимаю. Твой то коммит останется.
А фиг его знает, останется он или нет.
Например файлы неаккуратно перенесут из одной директории в другую, и у них история обнулится. Или будет коренной апгрейд VCS, который что-то случайно потрёт. Или вообще переезд на новую платформу. Это всё реальные случаи.
Не помню чтоб я видел когда-нибудь в конторских VCS-ах больше трёх лет истории, хотя иногда пытался её оттуда достать. Но и настоящих крэшей тоже не помню - вроде оно всегда живо в режиме "зачекинить-зарефрешить".
no subject
Date: 2015-02-12 07:17 pm (UTC)Вот git, кстати, это интересная история, которой еще не было.
Было же как: централизованный репо, один на контору, который как-то бэкапится. Или несколько репо под разные проекты, но все равно - центральные.
А вот что что происходит в конторах, когда у них хотя бы лет 5 как живут распределенные репозитории и у каждого разработчика есть свой локальный - безумно интересно будет еще через 5 лет посмотреть.
С одной стороны, оно не крэшится фатально.
С другой - вот когда закрэшится, поднимут с бэкапа, а локальные уже убежали вперед, вот это вот прикол.
no subject
Date: 2015-02-12 07:24 pm (UTC)А там есть RCS/
То есть минимум с 94-го года могу достать историю (не помню, правда, есть ли annotate у rcs)
21 год с version control, епта!
no subject
Date: 2015-02-12 08:08 pm (UTC)Теперь шанс 50 на 50 - или воткну, или забью.