Expérience avec le contrôle de version locale de la copie de travail SVN?

Question

Sur mon lieu de travail, nous utilisons SVN et TortoiseSVN (Windows XP) en tant que client. J'ai un long trajet et travaille hors ligne pendant cela.
Maintenant, j'aimerais avoir une sorte de "extended undo" localement; c'est-à-dire que j'aimerais avoir le contrôle de la version locale de ma copie de travail SVN, afin d'oser refactoriser par exemple.
La commutation complète par ex. git, mercurial etc. n'est pas une option car la société utilise SVN.

Ce que je voudrais savoir si quelqu'un a une expérience dans la version de la copie de travail SVN locale, peut-être en exécutant un git local ou similaire?
Y a-t-il des inconvénients potentiels? (peut-être jouer avec des dossiers .svn ou similaire)

Answer 1

que je fais habituellement comme ceci:

1. Get dépôt SVN comme copie de travail.
2. Initialisez le référentiel Git dans cette copie de travail.
3. Hack pirater hack;
4. Validez mon dépôt Git.
5. Mise à jour de la part de la société SVN.
6. Résoudre les conflits.
7. S'engager auprès de la société SVN repo une fonctionnalité complète.

Answer 2

J'utilise Git comme un client Subversion local pour le travail et ça marche très bien. Lorsque vous effectuez un git svn clone d'un référentiel Subversion, l'extraction que vous obtenez n'a pas les répertoires cachés .svn, mais est à la place un référentiel Git complet dans son propre droit. La possibilité d'utiliser des branches locales et légères pour organiser mon propre développement est une fonctionnalité qui me tue.

Les autres fonctionnalités que j'utilise tout le temps sont git stash, les validations par étapes et git add -p.

Answer 3

La dernière fois que j'ai vérifié le statut de SVN, la prise en charge de l'archivage local était toujours un plan de fonctionnalité à long terme. Git, d'un autre côté, est définitivement une option, avec git-svn. Autrement dit, si votre architecture est Unix, AFAIK, git-svn n'est pas encore supporté sur la plate-forme Windows.

Answer 4

Vous pouvez créer un aperçu des travaux, en utilisant svn export, puis créer votre propre dépôt subversion et utiliser l'instantané à partir du référentiel de travail comme checkin initial.

Ensuite, vous pouvez apporter vos modifications et utiliser Subversion (votre copie du dépôt local) jusqu'à ce que vous avez terminé. Bien sûr, vous pouvez effectuer une fusion régulière à partir du référentiel de travail principal pour vous assurer que votre contenu est à jour. Enfin, lorsque votre refectation est terminée, faites simplement un snapshot d'export svn de votre référentiel local et fusionnez-le dans votre référentiel de travail principal.

C'est un peu grossier mais c'est la seule façon de gérer ce type de flux de travail.

Si vous avez un accès régulier au travail. Vous pouvez créer une branche du contenu et de travailler sur la branche à partir du référentiel de travail exclusivement et utiliser la méthode de dépôt local lorsque vous avez besoin de votre fonctionnalité d'annulation prolongée. À ce stade, bien sûr, l'utilisation d'un système de contrôle de version local ne vous limitera pas à la subversion, alors faites votre choix.

Answer 5

Rien n'empêche d'exécuter le serveur SVN local. Je l'utilise de cette façon.

Answer 6

Git serait une bonne solution (parce que vous pouvez faire et fusionner plusieurs branches très facilement), mais:

• lors de la réimportation votre modification svn, vous devez nettoyage d'abord les nombreuses branches intermédiaires vous avez créé sous git;
• git-svn ne fonctionne pas avec la distribution Windows de Git, vous voudrez peut-être utiliser une image virtuelle Linux si vous travaillez sous Windows
• Si vous pouvez faire courir git-svn, utiliser des scripts Ruby git2svn et svn2git , comme décrit dans this question

Answer 7

Vous pouvez essayer SVK qu'un VCS décentralisé basé sur subversion. Il peut être utilisé pour refléter le référentiel officiel sur votre ordinateur portable et synchroniser vos commits avec le tronc officiel.