немонотонные таймстампы коммитов в свн

Почему они просто не используют mercurial?

Вон даже heptapod есть, куда некоторые проекты переместились с bitbucket.

У них это автоматом генерится? То есть как заранее иначе узнать, что кто-то не закоммитит с таким же номером?

На гитхабе в их репе я вижу, что внутри коммитов есть текст вида Change-Id: I94fbffbe359be954bf769299420d1df97b2da184

У них это автоматом генерится?

Да.

То есть как заранее иначе узнать, что кто-то не закоммитит с таким же номером?

Номера выдаёт центральный Git сервер по триггеру если не ошибаюсь.

На гитхабе в их репе я вижу, что внутри коммитов есть текст вида Change-Id: I94fbffbe359be954bf769299420d1df97b2da184

Это другой номер для патчей в Gerrit.

Ты никогда не видел корпоративную svn-монорепу на пару сотен гигов и с историей лет так на 20? Если это перевести на гит - там будут сратые сотни терабайт и юзать её станет невозможно. Можно взять hg, но блин по опыту во время мержа можно просто пойти обедать, он адищенски тормозит если репа больше пары гигов

Я не фанат монореп, если что, просто большие компании очень их любят

Если это перевести на гит - там будут сратые сотни терабайт и юзать её станет невозможно.

Почему? У Git проблемы с эффективностью хранения данных? Где про это можно почитать?

Ты никогда не видел корпоративную svn-монорепу на пару сотен гигов и с историей лет так на 20? Если это перевести на гит - там будут сратые сотни терабайт и юзать её станет невозможно.

Linux kernel, Chromium, LLVM довольно большие проекты на git, и вроде работают…

Linux kernel, Chromium, LLVM довольно большие проекты на git

Да, но это все репы одного проекта. Ты монорепу кого-нибудь из faang хоть раз видел? Это не только «хромиум или ллвм», это натурально все проекты компании в одном огромном дереве. Представь репу в 300 ллвм разом, которая меняется с соответствующей частотой. Почему будет жопа смотри ниже

Почему? У Git проблемы с эффективностью хранения данных? Где про это можно почитать?

Это не проблемы, это дизайн системы. Гит на каждое изменение вместо диффа создаёт снапшот файла. Заменил строку - снапшот, заменил букву - снапшот. Подробнее https://git-scm.com/book/en/v2/Getting-Started-What-is-Git%3F

На самом деле все не совсем так просто и гит таки жмёт снапшоты и юзает дельты, тем самым ужимая размер репы. Но тут есть ещё один нюанс, который тоже есть по ссылке - гит это локальная vcs. То есть у тебя локально должна лежать вся репа разом, что для монорепы ад и погибель. В случае svn у тебя локально лежит только одна ревизия, то есть даже если на сервере нужно 100500 терабайт чтоб поддерживать весь этот жирный зоопарк, локально у тебя будут лежать от силы 10-20 гиг.

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

В случае svn у тебя локально лежит только одна ревизия, то есть даже если на сервере нужно 100500 терабайт чтоб поддерживать весь этот жирный зоопарк, локально у тебя будут лежать от силы 10-20 гиг.

Даже более того, в случае свн может лежать не ревизия всей репы, а только одной директории из неё, что ещё меньше.

монорепы

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

Да, это тоже есть. Но вообще из гита тоже можно слизать только часть дерева

https://git-scm.com/docs/partial-clone

Просто это слегка новая фича и поддерживается она далеко не всегда, оно кажется всего года два назад вышло

Ладно, а решение темы то какое?

В репе на основе svn в большой компании нет ничего плохого. Но я почему-то о уверен, что помимо самого svn сервера вокруг него навешано куча всего другого, включая автоматическое тестирование, какая-нибудь привязка к текущему task и прочее.

Сделал как хотел эти исправленные таймстампы, вроде ничего не сломалось.

Если что, команда такая:

svn propset --revprop -r HEAD svn:date "yyyy-mm-ddThh:mm:ss.uuuuuuZ"

Для того что работало надо разрешить это на сервере, я сделал такой pre-revprop-change хук:

#!/bin/sh

REPOS="$1"
REV="$2"
USER="$3"
PROPNAME="$4"
ACTION="$5"

date >> /svn/log/repo3.propchg.log
echo "repos=$REPOS rev=$REV user=$USER propname=$PROPNAME action=$ACTION" >> /svn/log/repo3.propchg.log
echo "propval --- old +++ new" >> /svn/log/repo3.propchg.log
echo "-------------------------------------------------------------" >> /svn/log/repo3.propchg.log
/usr/local/bin/svn propget --revprop -r "$REV" "$PROPNAME" "file://$REPOS" >> /svn/log/repo3.propchg.log
echo "+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++" >> /svn/log/repo3.propchg.log
cat >> /svn/log/repo3.propchg.log
echo >> /svn/log/repo3.propchg.log
echo "=============================================================" >> /svn/log/repo3.propchg.log

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:log" ]; then
  echo "accepted" >> /svn/log/repo3.propchg.log
  echo >> /svn/log/repo3.propchg.log
  exit 0
fi

if [ "$ACTION" = "M" -a "$PROPNAME" = "svn:date" ]; then
  echo "accepted" >> /svn/log/repo3.propchg.log
  echo >> /svn/log/repo3.propchg.log
  exit 0
fi

echo "discarded" >> /svn/log/repo3.propchg.log
echo >> /svn/log/repo3.propchg.log
echo "Changing revision properties other than svn:log is prohibited" >&2
exit 1

Такую прогу чтоб брать таймстамп из таймстампа файла (сам файл выбирал вручную т.к. немного надо раз было) getftime_as_svndate.c

#include <sys/types.h>
#include <sys/stat.h>
#include <stdio.h>
#include <string.h>
#include <time.h>
#include <errno.h>

typedef unsigned int uint;
int main(int argc, char **argv) {
  struct stat sb;
  struct tm *tm;
  int r;
  char const *fn;
  if(argc==3 && !strcmp(argv[1],"-L")) {
    fn = argv[2];
    while((r = stat(fn, &sb))<0) if((r=errno)!=EINTR) {
      fprintf(stderr, "stat(%s) error %d (%s)\n", fn, r, strerror(r));
      return -1;
    }
  } else if(argc==2) {
    fn = argv[1];
    while((r = lstat(fn, &sb))<0) if((r=errno)!=EINTR) {
      fprintf(stderr, "lstat(%s) error %d (%s)\n", fn, r, strerror(r));
      return -1;
    }
  } else { fprintf(stderr, "Usage: getftime_as_svndate [-L] <filename>\n"); return -1; }
  if(!(tm = gmtime(&sb.st_mtime))) {
    fprintf(stderr, "gmtime(mtime of %s) failed\n", fn);
    return -1;
  }
  printf("%04u-%02u-%02uT%02u:%02u:%02u.%06uZ",
    (uint)(tm->tm_year+1900), (uint)(tm->tm_mon+1), (uint)(tm->tm_mday),
    (uint)(tm->tm_hour), (uint)(tm->tm_min), (uint)(tm->tm_sec), (uint)(sb.st_mtim.tv_nsec/1000));
  return 0;
}

И такой скрипт ci-setdate.sh

#!/bin/sh -e

SVNBIN=/usr/local/bin/svn

if [ "q$1" = "q" ]; then
  REV="HEAD"
else
  REV="$1"
fi

if [ "q$2" = "q" ]; then
  echo "Usage: ci-setdate rev ref_filename"
  exit 1
else
  TT=`getftime_as_svndate "$2"`
fi

OLD=`$SVNBIN propget --revprop -r "$REV" svn:date`

$SVNBIN propset --revprop -r "$REV" svn:date "$TT"

echo "changed rev $REV date $OLD -> $TT"

В репе на основе svn в большой компании нет ничего плохого

В самой технологии - нет, все норм. Но вот скидывать вообще весь код всех проектов в одну помойку это какой-то изврат.

Почему «помойку»? То что они на одном разделе жёсткого диска лежат тебя ж не смутит? Свн репозиторий это то же самое, только с контролем версий, причин его делить на части почти нет. Разве что что б номера коммитов были поменьше. А так соседние директории внутри одной свн репы полностью друг от друга независимы, пока ты специально их не свяжешь каким-нить копированием/перемещением файла из одной в другую. И то эта связь ни на что почти не повлияет в будущем.

свн может лежать не ревизия всей репы, а только одной директории из неё

О, я помню проект в SVN десять лет назад. Здесь синхронизируй, здесь не синхронизируй. Иначе хрен соберётся. К счастью, недолго я там задержался. Здоровье сохранил.

Почему «помойку»?

Потому что идея монорепы это когда у тебя вместо версий вся компания (не команда, именно компания) «живёт» на транке.

Ещё раз - я не про «единый сервак с репой», это как раз абсолютно логично, все как ты написал. Я про «одну репу на всех и все из неё собирают», без версий, пакетов и прочего, прямо с транка, с перекрестными зависимостями во все поля. Ну и как написали выше «помимо самого svn сервера вокруг него навешано куча всего другого, включая автоматическое тестирование, какая-нибудь привязка к текущему task и прочее.» Репозиторий это уже много лет как нечто большее чем замена электронной почты для пересылки патчей.

У апологистов монорепы обычно два аргумента: «вместо тонн боли от смены версий чуть-чуть боли при каждой пересборке» и «все в компании видят если вдруг что-то сломали и могут это починить/предупредить». Могу рассказать почему эти две идеи жизнеспособны только во влажных мечтах whiteboard-кодеров если это не очевидно.

Это ты ещё IBM/Rational ClearCase не использовал. Возможно, это был прорыв, когда оно только появилось, но по ощущениям, комитет сел и попытался придумать максимально навороченную систему контроля версий. Только большинство фич в ней, не облегчали, а осложняли разработку. Видимо, придумывали не разработчики а менеджеры.

При этом у неё ещё были запредельные системные требования для своего времени, необходимость минимум в одном выделенном администраторе, и стоимость в районе нескольких тысяч $$$ на рабочее место.

Почему-то до сих пор вспоминается как страшный сон. Но оно до сих пор существует, продаётся и используется. Я периодически спрашивал коллег с того места работы, где столкнулся с ней 12+ лет назад, они вроде до сих пор с неё не ушли.

которая либо только увеличивается, либо только убывает

НЕ увеличивается либо НЕ убывает.

Ну да.

Свн … Всем удобно

Как человек, много работавший с svn, hg и git могу сказать, что svn - очень удобная штука. Там есть история ревизий, всё можно посмотреть, классно. Классно как путешествие на запорожце по сравнению с пешим путешествием на такое же расстояние. Но несколько не так удобно, как на современном автомобиле…

Вот действительно, когда работал с svn, меня в принципе всё более-менее устраивало. Когда пересел на DVCS, то довольно скоро вообще перестал понимать, как я раньше без них работал??? Просто они открывают новые горизонты удобства разработки, о которых раньше не догадывался. Да хотя бы такая необходимая вещь, как деление доработки на несколько (до нескольких десятков) коммитов, которые в процессе реализации и тестирования подправляешь, - это в svn если и можно делать, то жутчайшими костылями.

коммитов, которые в процессе реализации и тестирования подправляешь, - это в svn если и можно делать, то жутчайшими костылями.

Жутчайший костыль - это то что ты описал. Коммит это и есть очередная правка. «Править правку» это бред.

Коммит это и есть очередная правка. «Править правку» это бред.

Вы просто неопытный. Это не страшно. Потом поймете, что править правку - это очень нужное и важное дело.

Правки в ветке разработки отражают процесс разработки. Исправил что-то - закоммитил. Старые коммиты это старые коммиты, трогать их не надо. Когда есть готовый результат - мержишь в тестовую или ещё какую предрелизную ветку, там уже коммиты отражают добавленный функционал / решенные пользовательские проблемы. А порча истории это крайне вредное дело.

Если вы манагер, который считает, что следит за рабочим процессом разработчиков по сырым закоммиченным ошметкам кода в репозитории, то мне жаль ваших разработчиков.

История коммитов не должна отражать «процесс разработки», если его понимать как метания разработчика от одной идеи к другой, фиксы, эксперименты и переделки.

История коммитов для доработки должна быть кратчайшей последовательностью минимальных логически завершенных изменений кода, реализующей данную доработку. Это необходимо в целях упрощения поддержки.

Ладно, скажу по-другому. То, что тебе нужно, может быть чем угодно, но то, что ты описал, не является системой контроля версий. Версия - это именно зафиксированное состояние разработки на некоторый момент времени. Ты что-то дорабатываешь и получаешь следующую версию. Коммит - разница между соседними версиями. А то, что у тебя - система деления разработки на подзадачи, или ещё что-то, но называть это системой контроля версий и сравнивать с системами контроля версий - не надо. Свн - именно система контроля версий, её первичная функция - логировать все модификации файлов с таймстампами этих изменений, и давать возможность откатить состояние кода на любой указанный момент времени.

То, что тебе нужно

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

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

Версия исходного кода - это зафиксированное содержимое исходного кода. Если 2 версии можно сравнить, переходить с одной на другую, а также если по двум версиям предоставляется возможность определить, что одна была до, а другая - после, то систему уже можно назвать системой контроля версий. Поэтому svn, hg и git являются системами контроля версий. Странно, что приходится объяснять очевидные вещи. Кстати, если система контроля версий допускает возможность удаления какой-то версии, то это совершенно не лишает её права называться системой контроля версий.

давать возможность откатить состояние кода на любой указанный момент времени

Откатить состояние кода на любую версию система контроля версий должна. А «на любой указанный момент времени» - это фича централизованных систем контроля версий. Мне за всё время работы с svn она не разу не требовалась. Вот как-то не возникало необходимости откатываться на «вчера, аккурат после обеда». Обычно смотришь историю изменений и откатываешься на конкретную интересующую тебя версию. Если кому-то требуется смотреть, в какие моменты времени происходили добавления изменений в определённую ветку в гите, - это элементарно реализуется на стороне git-сервера логированием в соответствующем хуке. А т.к. в гите одним атомарным изменением в ветку может добавиться сразу несколько коммитов, то и хук их тоже сможет все сразу показать.

Странно, что приходится объяснять очевидные вещи.

Странно, что ты очевидных вещей не понимаешь. Правя старые коммиты, ты безвозвратно затираешь старые версии, включая информацию о том, что там было раньше а что позже. Гит то умеет хранить историю, но при твоём способе использования он её нормально не хранит.

Обычно смотришь историю изменений и откатываешься на конкретную интересующую тебя версию

Только вот у тебя её нет, этой истории. Потому что вместо того, чтобы дописать новую правку в конец, ты её всунул задним числом куда-то в середину, да ещё и не отдельным пунктом а объединил с чем-то. А вот сломается у тебя что-то после этой правки - надо будет её откатить (или хотя бы чётко видеть в чём именно она состояла). В нормальных vcs это делается откатом соответствующего коммита. В твоей наркоманской системе это выльется либо в ручное вспоминание что ж ты там менял, либо в жуткое прикостыленное логирование правок коммитов (которое и будет выполнять функции нормальной vcs в данном случае).

Вы что, думаете, историю в гите правят в основной ветке разработки? Вы вообще представляете себе хотя бы примерно workflow подавляющего большинства разработчиков, работающих с git? Если нет, зачем вообще о чем-то спорите, тратя своё и чужое время?

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