La meilleure façon de créer un miroir SVN?

Je cherche actuellement la meilleure façon de configurer un miroir SVN. Je vois actuellement trois possibilités avec leurs propres inconvénients:

Avoir un crochet post-commit SVN qui bloque et synchronise via svnsync. Le problème ici est évidemment que la validation est bloquée jusqu'à ce que les données soient transférées vers le miroir.
Avoir un crochet post-commit SVN qui ne bloque pas et ne se synchronise pas via svnsync. Ici, je vois le problème suivant, plus subtil: Imaginez que quelqu'un archive un gros fichier et que quelqu'un d'autre peu de temps après archive un petit fichier. Étant donné que la validation n'est pas bloquante, deux processus svnsync pourraient être exécutés en même temps et le petit fichier pourrait dépasser le fichier BIG sur le chemin du miroir (cela semble très critique en temps et improbable, bien que possible en principe). Leur révision s'échangerait.
Synchronisez comme toutes les quinze minutes avec un cron-job. Même problème si un commit prend plus de 15 minutes et évidemment ce délai.

Ai-je oublié une possibilité? Ai-je eu quelque chose de mal? Des idées? Merci déjà!

Je devrais peut-être noter que la deuxième possibilité est celle suggérée par différents sites Web. Voir par exemple http://www.kirkdesigns.co.uk/mirror-svn-repository-svnsync

svn

— roesslerj
source

Étant donné que la validation n'est pas bloquante, deux processus svnsync pourraient être exécutés en même temps et le petit fichier pourrait dépasser le fichier BIG sur le chemin du miroir (cela semble très critique en temps et improbable, bien que possible en principe). Leur révision s'échangerait. Ce n'est pas possible, svnsync réplique les validations à mesure qu'elles sont écrites dans le référentiel. Ils apparaîtront toujours dans l'ordre de révision.

— Dave Cheney

Vous pouvez essayer une approche similaire à celle que nous utilisons chez Atlassian

https://www.atlassian.com/blog/archives/subversion_replication_at_atla?_ga=2.217251286.1933127788.1517539727-1159165484.1517539727

Clause de non-responsabilité: Je suis actuellement un employé d'Atlassian, mais je n'ai pas été impliqué dans la mise en œuvre de cette solution (je la maintiens uniquement)

Comme je l'ai dit ci-dessus dans le commentaire, svnsync, exécuté à partir d'un référentiel distant se comporte de manière déterministe. Il ne peut pas appliquer de modifications hors service. Ainsi, le seul problème que vous rencontrez en utilisant un référentiel distant est la quantité de retard due à la propagation de l'ensemble de modifications.

— Dave Cheney
source

+1 pour l'observation que svnsync ne peut pas déranger, le seul problème est la latence potentielle.

— Jim T

Vous avez tout à fait raison ... J'ai fait une stupide erreur de pensée. Ainsi, le crochet post-commit SVN simple et beau devrait le faire dans la plupart des cas. Dans le cas où la latence est un problème, on peut jeter un œil à l'article Atlassian référencé. Merci beaucoup!

— roesslerj

Sachez simplement que le hook post commit bloquera le committer jusqu'à ce que le hook soit terminé. Je ne suis pas sûr de ce qui se passe si le hook de post-validation échoue, je ne pense pas que la validation soit annulée, mais ce sera au moins déroutant.

— Dave Cheney

Eh bien, en utilisant le hook post-commit, vous pouvez émettre une commande qui retourne immédiatement (par exemple via 'commande &' sur linux), sans la bloquer. Étant donné que le hook est post-commit, il ne peut pas annuler la validation. Si svnsync échoue, la prochaine svnsync doit synchroniser deux révisions, ce qu'elle fait simplement. Le problème se produisant ici, je déposerais sous la latence du sujet.

— roesslerj