Le Mon, 4 Apr 2011 16:58:06 +0200, Benjamin POUSSIN <poussin@codelutin.com> a écrit :
On Mon, 4 Apr 2011 10:45:19 +0200 Manoël <manoel.fortun@gmail.com> wrote:
...
Quand tu add/delete, ça commit tout seul (mauvaise idée) où faut commiter à la main derrière (bonne idée) ?
Non, ca commit tout seul, sinon il faut retenir tout un tas d'information en local qui complexifie tout.
L'idée ici (pour l'instant) n'est pas de remplacer ou réécire une gestion de version de source comme git, svn, ou autre. Mais juste d'avoir un moyen de récupérer un ensemble d'objet wikitty sur le filesystem local pour pouvoir facilement les modifier avec les outils de dev traditionnel puis repousser ces fichiers en objet wikitty dans un WikittyService.
Si l'on veut une vrai gestion de version, il faut, une fois les objets récupérer en fichier les mettre dans un SVN ou autre.
Moi j'ai l'impression qu'on s'en approche quand meme enormement... Il serait peut etre interessant de voir comment SVN ou GIT fonctionne "mecaniquement" et en retirer des indications sur nos besoins.
SVN ne fait pas le delete ou le add avec un commit autmatique car il gere un numero de revision unique pour un ensemble de modification avec un message de commit.
Ce qui n'est absolument pas notre cas, nous n'avons pas de message de commit et encore moins un numero unique (equivalent a une transaction) pour un ensemble de modification. Chaque objet a son propre numero de version.
Donc que tu commit juste apres la commande remove ou que tu doives faire le commit a la main plus tard au final on a exactement le meme resultat. Donc le mieux est de faire au plus simple "le remove, commit" (ce qui supprime simplement un tag de l'objet)
...
Sur la contrainte au commit (version locale au moins égale à celle du WS), pourquoi pas (ça oblige le mec à faire un update avant de commiter et donc à voir les conflits), mais SVN, lui, fait le merge.
Il fait le merge lorsque ce ne sont pas les memes lignes qui sont modifier, sinon il fait des trucs super compliqué que j'aime pas :(. Dans un premier temps il faut faire au plus simple et implanter des mécanisme plus complexe par la suite (en utilisant des libs existantes)
Donc en gros avec une methode merge (fichier qui vient du serveur, fichier local):Status qui par exemple renome le local avec son numero de version+bak et sauve celui du serveur avec le nom local
Par contre le status qui ressort serait ce qui a ete fait: - N: nouveau - U: update - B: backup - R: replace ...
comme ce que ressort un svn update
Puis par la suite, on pourra modifier seulement l'implantation de cette methode pour faire des choses plus intelligentes.
La seul question qui reste en suspend est comment savoir que l'objet local a ete modifié par rapport a la version du serveur ? On va peut-etre être obligé d'avoir dans le réperoire .wp (ou autre ;)) un répertoire orig qui contient le fichier dans sa version serveur.
Du coup, on peut savoir facilement si le fichier local a ete modifier (différence entre le fichier local et le fichier dans orig)
Idem pour le coté serveur grace à la version qui a été modifié.
Dans le meme ordre d'idée que précédement, on peut sans doute avoir une reponse dans le fonctionnement de SVN ou Git (avec un option sur git ou autre decentralisé je pense ) -- Yannick