Comment mettre à jour une branche SVN créée avec svn-copy?
noob question je sais, mais toutes les ressources que j'ai trouvées échouent ou m'ont donné le nouveau problème.
J'ai peu de succursales dans mon dépôt SVN. Tous les développeurs ont accès à sa branche personnelle. Chaque branche a été faite par une copie de la branche bêta.
svn copy svn://192.168.0.2/svn/example/branches/beta
svn://192.168.0.2/svn/example/branches/dev/devN
Maintenant, quand dev1 a fini de travailler, il fusionne son travail en beta (pwd = ./beta/)
svn merge svn://192.168.0.2/svn/example/branches/dev/dev1@4242 .
Eh bien, ma question est de savoir comment un autre développeur pourrait mettre à jour sa propre branche vers la dernière version bêta avec le changement de dev1
quand dev2 fait une fusion (après avoir validé sa propre modification | pwd = ./dev/dev2)
svn merge svn://192.168.0.2/svn/example/branches/beta@4242 .
Il reçoit ce message:
svn: E195016: Merge tracking not allowed with missing subtrees; try restoring these items first:
pointing his files. -> impossible to merge.
Est-il possible de "mettre à jour" une copie de branche?
Ce message d'erreur se produit lorsque quelqu'un supprime quelque chose sans en informer Subversion. Si vous deviez exécuter svn status sur cette copie de travail, le même chemin que celui auquel se plaint Subversion devrait s’afficher avec un ! dans la première colonne de la sortie. Cela signifie généralement que quelqu'un a utilisé une commande de système d'exploitation pour supprimer des chemins plutôt qu'une commande svn.
Si vous voulez vraiment que les chemins soient supprimés, vous pouvez résoudre ce problème en informant Subversion à ce sujet en utilisant la commande svn rm. Les chemins apparaîtront comme supprimés avec une D dans la première colonne de la sortie de statut et votre fusion devrait se poursuivre (bien que des conflits d'arborescence puissent exister).
Si vous voulez les détails sanglants, voyez numéro n ° 2915 du projet Subversion qui explique pourquoi ce message d'erreur a été ajouté.
Si vous travaillez sous Windows et que le chemin d'accès dépasse 256 caractères, Windows commencera à être méchant à propos de certaines choses. Pour résoudre ce problème, je crée généralement l’espace de travail directement dans un répertoire court du système de fichiers racine (par exemple, C:\WRK). Le chemin utilisé est bien plus court que le répertoire C:\Users\nom_utilisateur\Bureau \. Une fois mon espace de travail créé, j'ajoute un raccourci sur mon bureau pour un accès facile.
Je reçois cette erreur et je viens de faire une vérification avec TortoiseSVN. Rien n’a été supprimé. J’ai trouvé qu’à la fin d’un long chemin, un répertoire "commun" avait été créé, qui ne s’affiche pas lorsque je me rends dans le rapport. Si je supprime le répertoire parent et effectue une mise à jour, le répertoire "commun" réapparaît. Le répertoire parent affiche également un X rouge qui indique que TortoiseSVN pense que quelque chose a été supprimé via une commande de système d'exploitation, plutôt qu'avec une commande de suppression SVN.
Je pense qu'il y a un bug quelque part dans le code. Je ne sais pas si cela a à voir avec la longueur du chemin d'accès (un problème pour Windows 7?) Ou s'il y a un autre problème en cours.