Conversion projet wordpress au vendeur procédure de branche
Si vous utilisez svn pour la première fois que je suppose que vous n'avez pas commencé avec une copie wordpress propre, ramifiée à partir de là et modifié la version ramifiée, avez-vous?;)
Si tel est le cas, vous pourriez avoir un problème entre vos mains.
Contexte
Contrairement SVN "diffs réguliers" fusion ne compare pas le code côté droit/dossiers avec le code côté gauche/dossiers. Alors que svn merge pourrait retomber dans un mécanisme semblable à un diff s'il ne trouve pas d'historique, je ne recommanderais pas de faire appel à ce mécanisme car il peut être sujet à des conflits inutiles.
La fusion SVN est utilisée pour reproduire les modifications qui ont été enregistrées dans l'historique SVN. C'est comme si on disait à un peintre "Hey tu sais comment cette photo a regardé avant que tu ajoutes cet arbre sur la colline? Cet arbre était génial! Regarde ici j'ai copié la même image de base mais maintenant c'est avec un coucher de soleil. Encore un arbre mais sur cette photo avec le coucher de soleil? " Le peintre pourrait peut-être reproduire l'arbre parce qu'il sait comment il l'a fait. Il pourrait même avoir un brouillon quelque part.
L'image, c'est wordpress. Le peintre, son svn avec vous le commandant. L'arbre c'est vos modifications. L'image maintenant sur le thème du coucher de soleil est la version wordpress la plus récente.
Ce que vous avez probablement fait est de copier wordpress vanilla dans votre svn, de le modifier, de l'utiliser. Pour coller à l'exemple de l'image, l'historique contiendrait des commandes telles que "copier une image entière, ajouter une arborescence, ajouter des feuilles".
Maintenant, vous apportez une nouvelle version de wordpress, une nouvelle image pour ainsi dire et le mettre à côté de votre ancienne version modifiée. Le problème est, vous humain et intelligent savez à peu près la même image et même si la nouvelle version est différente, vous avez juste à copier l'arbre, SVN n'a pas cette connaissance. Pour SVN votre dossier Wordpress 1.7 (modifié) est complètement distinct de wordpress 1.8. Ils ne partagent aucun historique car rien dans le journal SVN ne l'indique. SVN est un snob bureaucratique n'est-ce pas? ;)
Maintenant, ce que les gens font pour permettre à svn de maintenir cette connexion historique entre wordpress 1.7, votre 1.7 modifié et le nouveau 1.8 est qu'ils utilisent branchement dès le début de leurs travaux.
Donc, vous commenceriez avec un wordpress 1.7 propre dans un dossier "vanilla-wordpress", stockez-le dans svn et branchez-le, disons, "my-modified-wp". Là vous bidouillez jusqu'à ce que vous ayez envie de mettre à jour wordpress de l'amont. Les gens téléchargent alors la dernière copie de wordpress remplacent leur wordpress de vanille et fusionnent le changeset résultant.
Dans l'exemple image commandes seraient celles-ci:
"Buy original picture
copy original picture as my picture
draw tree on my picture
draw sunset on original picture (someone else did that for you, aka update)
*reproduce* sunset on my picture too"
Vous pouvez reproduire proprement le coucher du soleil parce que vous savez comment l'image était avant le coucher du soleil a été appliqué. Cependant, votre problème est que vous n'avez pas démarré mais que vous avez modifié votre wordpress immédiatement. Ainsi, votre nouvelle copie de wordpress ne peut pas être facilement associée à votre version modifiée.
Une façon d'établir des relations d'histoire
download the **exact** wordpress version you started your project with
Put it into /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.7.1" to tag the import.
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/branches/my-new-modified-wordpress" or whatever your project/WP-edition is called.
Maintenant vient la partie trick Faire défiler le journal de retour svn de votre "vieux-modifié wordpress". Celui que tu n'as pas ramifié. Vous devez trouver la première révision après votre importation initiale de l'ancien wordpress. Une fois que vous avez trouvé cette révision que vous prenez son numéro et l'utiliser dans la seconde de ces deux commandes:
change into a local checkout of "/branches/my-new-modified-wordpress"
issue "svn merge -r **4**:HEAD http://svnserver.tld/repositorypath/my-**old**-modified-wordpress". If 4 was the first revision during which you made own modifications.
Vous dites svn ce qui suit: « Prenez tous les changements dans ma vieille branche entre la révision 4 et maintenant et reproduire eux sur ma nouvelle branche. "
Si tout fonctionne, vous devriez avoir deux branches identiques. l'ancien-modifié et le nouveau-modifié avec la légère différence que le nouveau-modifié a une histoire solide avec votre branche "/ vendeur/wordpress/current".
Cette ascendance vous permet de faire contunously les éléments suivants:
Download the wordpress version you wish to upgrade too and **overwrite** /vendor/wordpress/current
invoke "svn copy http://svnserver.tld/repositorypath/vendor/wordpress/current http://svnserver.tld/repositorypath/vendor/wordpress/1.9.3" to tag the new version.
change into local checkout /branches/my-new-modified-wordpress
issue "svn merge http://svnserver.tld/repositorypath/vendor/wordpress/current"
profit
Cette procédure, je décris avec moins storystelling au lien allready. Mais avant que cela puisse fonctionner, vous devez établir la relation d'ascendance entre les branches.
Subversion svn:externals file override?
Je sais qu'il a été grand-chose à lire :). Si vous envisagez de dessiner, pensez à "changer les commandes" et non pas aux états et tout ira bien.
C
Merci Cristoph pour votre explication claire. Vous avez bien résumé ma situation. C'est utile en soi car je vais maintenant savoir comment mettre en place de futurs projets. Je vais essayer de trier mon projet actuel en utilisant vos instructions, mais votre vue d'ensemble a été particulièrement utile. – Lemmy