2010-05-06 2 views
3

J'essaie de comprendre s'il s'agit d'un problème connu avec SVN 1.6.x Le développeur A modifie un fichier et le valide. Le développeur B modifie le même fichier. Essaie de le commettre et reçoit une copie locale périmée, ainsi qu'une mise à jour, puis un commit.subversion 1.6.x perdre des modifications à l'enregistrement

Cependant, les changements de développeur A sont perdues si le fichier résultant ne contient que la version développeur B vérifiée.

Nous pouvons voir cela dans les journaux. Cela semble se produire quand le même fichier est modifié mais dans des endroits différents.

Quelqu'un d'autre a-t-il vécu cela? Nous l'avons fait 4 ou 5 fois au cours des dernières semaines et nous avons perdu une demi-journée à chaque fois pour essayer de comprendre ce qui a été perdu, etc.

Nous commençons à perdre confiance en SVN . Devrions-nous envisager de passer à GIT ou Mercurial? Cela réglerait-il ce problème?

+1

C'est le cas d'utilisation multi-utilisateur de SVN, qui est utilisé par des centaines de milliers de développeurs sans problèmes. Il semble beaucoup plus probable que le problème est quelque chose que vos utilisateurs font. –

+0

Je suis désolé de dire "Nous commençons à perdre confiance dans SVN." vous n'avez pas compris comment SVN fonctionne. C'est le but. Si vous faites une mise à jour svn, vous serez informé si vous avez un conflit. Que vous devez résoudre ce conflit. Et SVN ne remplace pas les changements et aucun changement ne sera perdu. Dans l'histoire, le changement de Dev A est là. Pendant la mise à jour de svn une fusion est arrivée. Le Dev B devrait vérifier si cela est correct. Si la situation se passe comme vous l'avez décrit, il y a eu quelque chose que vous n'avez pas écrit. – khmarbaise

+0

Nous savons comment utiliser SVN :) Nous l'utilisons tous les jours depuis plus de 2 ans ... donc c'est une nouvelle chose. – Bernard

Répondre

1

Est-ce qu'un membre de votre équipe copie manuellement des fichiers et des dossiers afin que les informations de révision dans les dossiers .svn ne soient plus correctes?

Comme derobert décrit dans un answer à une question connexe, en écrasant les autres utilisateurs des modifications est possible si vous copiez manuellement vos fichiers modifiés dans un dossier SVN récemment mis à jour:

Voici comment la procédure nuke/copie peut annuler les changements d'autres personnes:

  1. Commander, obtenir r1;
  2. Modifier foo.c, donnant r1 + changements;
  3. Quelqu'un d'autre vérifie dans un changement Foo.c (vous ne savez pas qu'ils ont fait cela, bien sûr, et la façon normale de vérification est rompu pour vous), foo.c dans la prise en pension est maintenant r2;
  4. Maintenant, vous armez votre dépôt à l'exception de foo.c (r1 + changes);
  5. Vous faites un contrôle, obtenez foo.c r2.
  6. Vous remplacez foo.c par votre copie (r1 + modifications). Subversion, cependant, n'est pas conscient de cela, et pense que vous basé vos modifications sur r2, pas r1.
  7. Checkin, foo.c est maintenant r3, qui vient de perdre les changements de l'autre personne dans r2.
0

Si vous oubliez d'enregistrer votre fichier, puis effectuer une « mise à jour svn » (avec quel outil vous le souhaitez), puis enregistrez votre version locale du fichier à nouveau sur le fichier mis à jour, vous perdez les changements quelqu'un d'autre s'est engagé.

Mais ce n'est pas Subversions faute: Vous devez enregistrer vos modifications et recharger les fichiers après la mise à jour. La plupart des éditeurs ont des fonctionnalités pour cela et si vous utilisez des outils tels que Eclipse de Visual Studio, vous pouvez regarder des solutions Subversion intégrées pour vous aider.

+0

1. le gars dit que la fusion SVN est cassée. ce n'est pas l'OP qui ne sait pas utiliser SVN, mais vous qui ne prenez pas le temps de bien comprendre sa question. 2. Ce n'est jamais la faute de l'utilisateur lorsque le logiciel est mal conçu. Je recommande de lire quelques livres d'Alan Cooper et de Donald Norman. –

+0

Mais si vous mélangez et utilisez plusieurs produits, vous ne pouvez pas blâmer un seul d'entre eux pour avoir rompu votre utilisation de la combinaison. Surtout si l'un des autres n'a pas été conçu pour fonctionner ensemble. Je recommande de lire le manuel des produits que vous utilisez sur la façon de l'utiliser au lieu de recommander de lire sur un des modèles de conception différents. Le système a été conçu pour fonctionner de cette façon, tout comme les autres systèmes de contrôle de version. Passer à un VCS différent ou lire des livres de conception ne résoudra pas le problème. –