Travail autour pour ne pas “git svn clone” (nécessitant une histoire complète)
Je veux convertir un dépôt Subversion sous-répertoire (notée par module
ici) dans un dépôt git avec un historique complet. Il y a beaucoup de svn copy
opérations (Subversion appeler des branches) dans l'histoire de mon dépôt Subversion. La politique de diffusion a été que, après chaque sortie, ou d'autres branches créées, l'ancienne URL est inutilisé et la nouvelle URL remplace l'ancien contenant le travail.
De façon optimale, par mes lectures, il semble que cela devrait faire l'affaire:
$ git svn clone --username=mysvnusername --authors-file=authors.txt \
--follow-parent \
http://svnserver/svn/src/branches/x/y/apps/module module
(où branches/x/y/
représente la nouvelle branche). Mais j'ai une erreur qui ressemble à quelque chose comme ceci:
W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: '/svn/src/!svn/bc/100/branches/x/y/apps/module' path not found
W: Do not be alarmed at the above message git-svn is just searching aggressively for old history.
(Mise à jour: l'Ajout de l'option --no-minimize-url
à la ci-dessus ne permet pas de supprimer le message d'erreur.)
Le répertoire module
créé et peuplé, mais la Subversion de l'histoire du passé le plus récent svn copy
s'engager n'est pas importé (le dépôt git créée finit par avoir seulement deux commits lorsque je m'attendais à des centaines).
La question est de savoir comment exporter l'intégralité de la Subversion de l'histoire en présence de cette situation?
Cause Possible
-
À la recherche pour le message d'erreur, j'ai trouvé ceci: git-svn anonyme caisse échoue avec -s
qui était liée à cette Subversion question: http://subversion.tigris.org/issues/show_bug.cgi?id=3242Ce que je comprends par ma lecture, quelque chose dans la Subversion 1.5 changé sur la façon dont le client accède au référentiel. Avec les nouveaux Subversion, si il n'y a pas d'accès en lecture à un super répertoire du chemin d'accès d'URL (c'est vrai pour moi,
svn ls http://svnserver/svn
échoue avec403 Forbidden
), alors nous ne parvenons pas avec certains des opérations de Subversion. -
Jeff Fairley dans sa réponse souligne que les espaces de Subversion URL peut également provoquer ce message d'erreur (confirmation par l'utilisateur, Owen). Jeter un oeil à sa solution pour voir comment il a résolu le cas si votre
git svn clone
est un échec pour les mêmes resson. -
Dejay Clayton dans sa réponse révèle que si la plus profonde de la sous-répertoire de composants de direction et de tag svn url sont également appelés (par exemple
.../tags/release/1.0.0
et.../branches/release-candidates/1.0.0
) alors que cette erreur a pu se produire.
- Je ne peux pas parler pour les fonctionnalités, mais je peux pour l'avertissement. Vous pouvez ignorer les "Ignorant" erreur sur les bits. Il est sans rapport avec subversion.tigris.org problème est lié. Si quoi que ce soit, basée sur la lecture des git-svn source, il faut jeter un supplément d'erreur pour le tigre cas.
- Il me semble que l'alerte est liée au fait que le passé le plus récent
svn copy
je ne vais pas apprendre l'histoire importés. Lesvn copy
(changement d'URL ou de la création de la nouvelle branche) sont importés comme l'ajout de tous les fichiers jusqu'à présent créé. D'où mon dépôt git contient seulement deux commits quand je m'attends à des centaines. - Est-ce un dépôt public? J'ai juré, j'ai lu une question récemment où un apache projet a été de rejeter
git svn
clones avec le!svn
chemin de la syntaxe simplement parce que les administrateurs du projet ne voulais pasgit-svn
de prendre leurs pensions de bande passante pour une demi-journée. Pour la vie de moi je ne trouve pas la question. C'était un public projet de la fondation Apache, vous l'esprit. - Non, c'est le mal de la société repository privé! 🙂 Je n'ai pas accès en lecture à faire
svn ls http://svnserver/svn
- tous les autres répertoires d'accord. Il n'y a pas de blocage délibéré degit svn
. (Comme pour le dépôt Open Source, il semble qu'il aurait donné de meilleurs résultats et ont été un meilleur service à la juste organiser la mise en miroir par les responsables... 😉 - Je soupçonne que vous avez raison au sujet de l'accès en lecture problème; je viens de dire que l'erreur est erroné (à tout le moins, si il est jeté pour votre cas d'utilisation, il devrait être plus clair sur la cause du problème). Vous pouvez essayer le git liste pour cette.
- Yup, et nous devrions noter que je n'ai aucun problème à faire
svn log -v http://svnserver/svn/src/branches/x/y/apps/module
et de voir le passé de l'histoire de lasvn copy
barrière. Il devrait y avoir une façon de contourner ce possible pourgit svn
si les autorisations d'accès en lecture sont le problème ici, comme il me semble. - Je pense que si votre mise à jour est une solution, vous devriez avoir posté une réponse séparément, de sorte que cette question pourrait être marqué comme résolu.
- Je pense que vous avez raison. Faute de meilleures façons de le faire, j'ai déplacé mon mauvais goût solution de la question à un organisme indépendant de réponse, et accepté que la solution (en attendant une meilleure façon de le faire).
- Voir ma réponse ci-dessous pour savoir comment ce problème peut également se produire si vous avez le même nom de sous-répertoires dans les balises ou les branches.
Vous devez vous connecter pour publier un commentaire.
J'ai rencontré ce problème lorsque j'ai eu à l'identique-nommé sous-répertoires à l'intérieur des branches ou des étiquettes.
Par exemple, j'ai eu des balises
candidates/1.0.0
etreleases/1.0.0
, ce qui a causé la documentation de l'erreur, car le sous-répertoire1.0.0
apparaît entre les deuxcandidates
etreleases
.Par git-svn docs:
Ainsi, alors que la commande suivante a échoué à cause du même nom
candidates
etreleases
tags:la séquence de commandes suivantes fonctionnent:
Remarque que cela n'a fonctionné parce qu'il n'y avait pas d'autres conflits au sein de
branches
ettags
. Si il y en avait, j'aurais eu à résoudre de la même façon.Après avoir réussi à cloner le dépôt SVN, j'ai ensuite exécuté les étapes suivantes dans l'ordre: turn SVN balises dans le dépôt GIT balises; tour
trunk
enmaster
; tourner d'autres références dans les branches; et de déplacer à distance des chemins:Pas une réponse, mais peut-être le fragment de code qui vous manque (je m'intéresse à la migration ainsi, j'ai constaté que la partie de l'énigme).
Quand vous regardez la la documentation de git-svn, vous trouverez l'option suivante:
Cela correspond à la situation que vous avez, ainsi que
git svn
n'essayez pas de lire un niveau supérieur de l'arborescence du répertoire (qui sera bloqué).Au moins vous pouvez lui donner un essai ...
git svn clone --follow-parent
de commande, mais il n'a pas d'effet notable (il semble ne pas s'appliquer à que scénario – je ne suis pas en mesure d'utiliser le--stdlayout
,--branches
, ou--tags
options dû à la façon dont le référentiel est structuré).J'ai récemment migré à une longue liste de dépôts SVN à Git, et vers la fin rencontré ce problème. Notre structure SVN était assez bâclée, j'ai donc dû utiliser
--no-minimize-url
un peu. En règle générale, je voudrais exécuter une commande comme:Les derniers migrations j'ai couru a un espace dans l'URL. Je ne sais pas si c'est l'espace ou quelque chose d'autre, mais j'avais la même erreur que vous avez été voir. Je ne voulais pas entrer dans la modification des fichiers de configuration si je n'avais pas, et heureusement, j'ai fini par trouver une solution. J'ai fini par sauter le
-s --no-minimize-url
options en faveur de déclarer explicitement les chemins différemment.--follow-parent
à partir de votre exemple, mais je ne suis pas sûr que cela fasse une différence.""
autour du tronc/branches/tags chemins.svn ls http://[url]/svn
(est-il en donnant403
ou suivante). Personnellement, j'ai un sens de l'espace ne devrait pas d'importance -- après tout, il est beaucoup plus facile d'écrire des espaces-tolérante correcte du code perl que les scripts shell... 🙂--trunk
,--tags
, et--branches
. Il serait intéressant de voir votre[remote-svn]
sections s'ils ressemblent à ce que j'ai reçu après monsed
foo. Si j'ai la possibilité de le tester, ou si quelqu'un confirme que les conseils de l'utilisation de chemins relatifs pour trunk, tags, branches résolu le problème de permission, je vais marquer cette réponse la réponse choisie. Merci!!!.git/config
de cette conversion. Je n'ai pas de[remote-svn]
mais j'ai un[svn-remote]
. gist.github.com/jfairley/416393762c4642e20992[Je me rends compte de ce qui devrait être un commentaire sur Jeff Fairley de la réponse, mais je n'ai pas la réputation de poste en tant que tels. Depuis l'affiche originale a demandé pour la confirmation de l'approche travaillé, je suis en fournissant une réponse.]
Je peux confirmer que cette solution fonctionne pour le problème qu'il (et moi) a couru dans causées par des espaces dans le chemin d'accès. J'ai eu les mêmes exigences (clone d'un module à partir d'un repo SVN avec l'histoire), sauf que je n'avais pas de branches ou des étiquettes à se soucier que ce soit.
J'ai essayé plusieurs combinaisons de fournir le chemin complet vers le module dans l'URL (par exemple à l'aide de
--no-minimise-url
, en précisant--trunk
ou--stdlayout
), sans succès. Pour moi, le résultat est généralement un repo git avec un historique complet de tous les journaux, mais pas de fichiers que ce soit. Cela peut ou peut ne pas être le même problème FooF rencontré (pas d'accès en lecture sur le SVN), mais il est certainement causé par la présence d'un espace dans le chemin d'accès à mon module.Essayer à nouveau avec le SVN pensions de base comme l'URL et le chemin d'accès à mon module dans
--trunk
a fonctionné parfaitement. Après, mes .git/config ressemble à ceci:et suivantes
git
etgit svn
commandes sont en jetant pas d'erreurs à tous. Merci Jeff![C'est l'original de l'affiche de
parlerde l'écriture. Ci-dessous l'habitude d'être mise à jour à la question, mais comme il a résolu le cas - quoique de manière satisfaisante à mon goût - je vais poster une réponse défaut d'une meilleure solution.]Je n'aime pas cela, mais j'ai fini par faire
clone
découpé eninit
etfetch
avec l'édition de.git/config
entre (repopath=apps/module
,gitreponame=module
):Je ne pouvais pas trouver comment spécifier les branches sous-répertoire de la migration avec
git svn
- d'où la modification de la.git/config
fichier. La suite de différences unifiées illustre l'effet de la modification avecsed
:Que le réel désiré
HEAD
était dans une autre URL, j'ai fini juste ajouter un autre[svn-remote]
section de.git/config
:(dans la vie réelle expérience j'ai aussi ajouté quelques branches qui n'ont pas été ramassés par la première extraction), et l'extraction de nouveau:
De cette façon, j'ai fini par avoir la pleine Subversion de l'histoire migré vers le nouvellement généré le dépôt git.
Note-1 : j'aurais probablement pu juste dit à mon "coffre" pour être
branches/x/y/apps/module
que le sens de "tronc" pourgit-svn
semble fondamentalement le sens de gitHEAD
(Subversion concepts de tronc, les branches, les balises ont pas de profondeur technique de base, ils sont la matière de socialement convenu de la convention).Note-2 : probablement
--follow-parent
n'est pas nécessaire pourgit svn fetch
, mais je n'ai aucun moyen de savoir ou en expérimentant maintenant.Note-3 : Alors que la lecture de svn2git qui semble être un wrapper sur
git-svn
je n'ai pas réussi à voir la motivation, mais en voyant le désordre présentation des étiquettes que je sorte de l'obtenir maintenant. Je voudrais essayersvn2git
la prochaine fois, si je devais essayer de faire une fois de plus.P. S. C'est plutôt une façon maladroite de faire l'opération. Deuxième problème ici (pourquoi l'édition de la
.git/config
en externe a été nécessaire) semble être quegit svn
mise en œuvre strictement suppose la Subversion sociale des conventions à respecter pour l'obtention d'un diplôme (ce qui n'est pas possible si vous voulez juste pour migrer un sous-répertoire et non de l'ensemble du référentiel Subversion).TODO: Il serait utile d'avoir le format de la
.git/config
fichier expliqué ici qu'il se rapporte àgit svn
- par exemple, j'ai maintenant (après un an et demi, de la rédaction de l'original de la réplique) aucune idée de ce que l'[svn-remote "svn-newest"]
moyens ci-dessus. La même approche pourrait être automatisée par l'écriture d'un script, mais c'est au-delà de mon intérêt actuel dans le problème et que je n'ai pas accès à l'original du dépôt Subversion ou la réplication de la question.