git-svn fetch ne tire pas dans les dernières versions

Lorsque j'exécute une

git svn fetch

de mon référentiel, il ne retourne rien et ne met pas à jour même si il y a des nouveaux commits
sous svn.

[root]# svn log -l 1  http://example.com/trunk/client-resources/resource-pa
    r12958 | ing | 2011-08-22 18:29:57 -0500 (Mon, 22 Aug 2011) | 1 line
    SRGENERAL-1468 adding more arrays for pa
[root]# git-svn fetch
[root]# git log -1
    commit be19ae4c7d1a3c3da6dd90389aebd6d76792cc71
    Author: sltin <sltin@44b83e5a-25ef-0310-8dbe-ee0aa4f92a64>
    Date:   Wed Jun 22 14:30:53 2011 +0000

    Fixing the classpath.

    git-svn-id: http://example.com/trunk/client-resources/resource-common@12406 44b83e5a-25ef-0310-8dbe-ee0aa4f92a64

Remarque les différences de version. Le svn log listes 12958 et la commande git log listes les plus récentes
version svn comme 12406.

Je peux faire un reset 12406, puis une nouvelle extraction:

[root]# git svn reset 12406
    r12406 = be19ae4c7d1a3c3da6dd90389aebd6d76792cc71 (refs/remotes/git-svn)
[root]# git svn fetch
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12977 = 1b21f560b0354b28fe1a272d7723b1e6fa90a99c (refs/remotes/git-svn)
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12978 = bf22ea0151a364eb1ca1af37a7a907d5b5cc7420 (refs/remotes/git-svn)
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12987 = ce922c2eae07f6c12dbbd4175a9c61055b563ee3 (refs/remotes/git-svn)

Et quand je vérifie le journal versions, ils sont inchangés.

Comment puis-je obtenir git-svn pour récupérer les dernières versions de svn?

Edit:

J'ai trouvé la réponse, le svn de données est chargé dans un thread inactif qui devraient normalement être fusionnées dans la branche active, qui n'existe pas dans un dépôt nu. J'ai essayé de faire un reset, mais qui a besoin d'une branche active. La réponse finale est:

git reset --soft refs/remotes/git-svn

source d'informationauteur Starkii

23

git svn fetch seulement des copies de nouvelles révisions à votre local de l'objet de base de données, comme beaucoup git fetch – deux seulement de synchroniser les bases de données objet. Il ne sera pas de mise à jour de votre branche et de la copie de travail. Pour obtenir le nouvellement extraites des changements dans votre branche, l'utilisation git svn rebase; il ré-appliquer toutes vos modifications locales sur le dessus de la dernière version svn.

git svn rebase va faire une avance rapide quand il n'y a aucun local s'engage, de sorte qu'il ne devrait pas gâcher l'histoire. Vous pouvez également utiliser git merge --ff-only git-svn rapide vers la plus récente version svn (et abandonner quand il n'est pas rapide-transférables, c'est à dire pas un descendant direct)

Vous ne devez utiliser git svn reset quand en amont svn a changé l'histoire (svndump/svnadmin) et vous avez besoin de re-chercher les nouveaux commits, mais cela ne devrait jamais arriver (sinon le blâme de l'admin!)
6

J'ai trouvé la réponse, le svn de données est chargé dans un thread inactif qui devraient normalement être fusionnées dans la branche active, qui n'existe pas dans un dépôt nu. J'ai essayé de faire un reset, mais qui a besoin d'une branche active. La réponse finale est:
```
git reset --soft refs/remotes/git-svn
```
4

Je crois que vous voulez git svn rebase. Ceci est différent de la git pullmais de même que les deux impliquent deux étapes (extraction de la télécommande, puis rebase ou de fusion).

Vous pouvez également rebase seulement déjà récupéré s'engage à:
```
git svn rebase --local
```
Si vous avez des modifications locales, qui ne sont pas encore dans le SVN, git-svn vous replay (rebase) sur le dessus de la dernière SVN s'engage.
0

A le même problème ici, en 2018, avec la dernière git. Résolu en supprimant le .rev_map et index fichiers et exécutez à nouveau git svn fetch.
```
/.git/svn/refs/remotes/origin/trunk/.rev_map.<GUID>
/.git/svn/refs/remotes/origin/trunk/index
```
D'une certaine manière il a été collé sur incorrecte la dernière version svn de l'association dans le cache. Dans la mienne cas, c'est la r32 de révision qui, en fait, était la r31 révision (car r32 et r31 a clairement différents messages de commit, c'est de cette façon que j'ai détecté que) et il a été de montrer r32 révision avec le message de validation de la r31 révision.

Attention:

A attrapé un autre problème. Le git pull origin trunk:master dans la mine de cas a revenir modifications avant de les indexer. Afin de NE PAS FAIRE le tirant. Faire de la rebase et push avant la pull à propager le fixe modifications sur le dépôt distant.

Vous devez vous connecter pour publier un commentaire.