git-svn : quel est l'équivalent de `svn switch --relocate` ?

Question

Un dépôt svn dont je suis le miroir via git-svn a changé d'URL.

Dans le svn de vanille, il suffit de faire svn switch --relocate old_url_base new_url_base .

Comment puis-je faire cela en utilisant git-svn ?

Le simple fait de changer l'url svn dans le fichier de configuration échoue.

Answer 1

Cela répond assez bien à ma situation :

https://git.wiki.kernel.org/index.php/GitSvnSwitch

J'ai cloné en utilisant le file:// et souhaitait passer au protocole http:// protocole.

Il est tentant d'éditer le url dans les [svn-remote "svn"] section de .git/config mais en soi, cela ne fonctionne pas. En général, vous devez suivre la procédure suivante :

1. Changez le svn-remote url au nouveau nom.
2. Exécuter git svn fetch . Ceci doit récupérer au moins une nouvelle révision de svn !
3. Changez le svn-remote url à l'URL d'origine.
4. Exécuter git svn rebase -l pour faire un rebasement local (avec les changements qui sont arrivés avec la dernière opération de récupération).
5. Changez le svn-remote url à la nouvelle URL.
6. Maintenant, git svn rebase devrait fonctionner à nouveau.

Les âmes aventureuses voudront peut-être essayer --rewrite-root .

Answer 2

Vous pouvez voir si ce qui suit fonctionne bien :

1. Si svn-remote.svn.rewriteRoot n'existe pas dans le fichier de configuration ( .git/config ) :

   git config svn-remote.svn.rewriteRoot <currentRepositoryURL>

2. Si svn-remote.svn.rewriteUUID n'existe pas dans le fichier de configuration :

   git config svn-remote.svn.rewriteUUID <currentRepositoryUUID>

   En currentRepositoryUUID peut être obtenu à partir de .git/svn/.metadata .

3. git config svn-remote.svn.url <newRepositoryURL>

Answer 3

Malheureusement, la plupart des liens dans ces réponses ne fonctionnent pas, je vais donc reproduire un peu d'information du site Web de la Commission européenne. wiki git pour référence future.

Cette solution a fonctionné pour moi :

• Modifier le svn-remote url (ou fetch chemin) dans .git/config pour pointer vers le nouveau domaine/url/chemin

• Exécuter git git svn fetch . Ceci doit récupérer au moins une nouvelle révision de svn !

• Si vous essayez git svn rebase maintenant, vous obtiendrez un message d'erreur comme celui-ci :

  Unable to determine upstream SVN information from working tree history

  Je pense que c'est parce que git svn est confondu par le fait que votre dernier commit avant le fetch aura un git-svn-id pointant vers l'ancien chemin, qui ne correspond pas à celui trouvé dans .git/config .

• Comme solution de contournement, modifiez svn-remote url (ou fetch ) vers le domaine/url/chemin d'origine.

• Exécutez maintenant git svn rebase -l à nouveau pour effectuer un rebasement local avec les modifications apportées par la dernière opération de récupération. Cette fois-ci, il sera travail, apparemment parce que git svn ne sera pas confondu par le fait que la git-svn-id de la nouvelle tête ne correspond pas à celle trouvée dans .git/config .

• Enfin, changer svn-remote url (ou fetch ) vers le nouveau domaine/url/chemin d'accès

• A ce stade git svn rebase devrait fonctionner à nouveau !

L'information originale a été trouvée aquí .

Answer 4

Git svn s'appuie fortement sur l'URL svn. Chaque commit qui est importé de svn possède une URL git-svn-id qui inclut l'URL svn.

Une stratégie de relocalisation valable consiste à appeler git-svn clone sur le nouveau dépôt et fusionner les changements sur ce nouveau dépôt. Pour une procédure plus détaillée, voir cet article :

http://www.sanityinc.com/articles/relocating-git-svn-repositories

Answer 5

git filter-branch

Ce script , tiré de un article de blog a fonctionné pour moi. Fournir l'ancien et le nouveau repo URL comme paramètre, comme pour svn switch --relocate .

Le script appelle git filter-branch pour remplacer les URL de Subversion dans les git-svn-id dans les messages de validation, les mises à jour .git/config et met également à jour git-svn en recréant les métadonnées à l'aide de git svn rebase . Alors que git svn clone pourrait être la solution la plus robuste, la filter-branch Cette approche est beaucoup plus rapide pour les gros dépôts (heures contre jours).

#!/bin/sh

# Must be called with two command-line args.
# Example: git-svn-relocate.sh http://old.server https://new.server
if [ $# -ne 2 ]
then
  echo "Please invoke this script with two command-line arguments (old and new SVN URLs)."
  exit $E_NO_ARGS
fi

# Prepare URLs for regex search and replace.
oldUrl=`echo $1 | awk '{gsub("[\\\.]", "\\\\\\\&");print}'`
newUrl=`echo $2 | awk '{gsub("[\\\&]", "\\\\\\\&");print}'`

filter="sed \"s|^git-svn-id: $oldUrl|git-svn-id: $newUrl|g\""
git filter-branch --msg-filter "$filter" -- --all

sed -i.backup -e "s|$oldUrl|$newUrl|g" .git/config

rm -rf .git/svn
git svn rebase