Le 30/03/2011 14:12, Manoël a écrit :
1) Alors si je saisie bien dans l'usage on se servira de wikitty plublication comme maven en ligne de commande un peu comme suit: wp commit [--recursion (true|false)] [--ws (url du WikittyService)] [répertoire à pousser]
Vu qu'il s'agit d'un ensemble d'opération sur des ressources Web, je dirai qu'il faut tendre vers du REST. Détail : normalement, t'as pas besoin de passer l'url du WS vu quelle est dans le fichier caché mentionné question 6.
2) Quand on dit qu'on peut récupérer un ensemble de wikitty à partir d'un label on parle des nom ou de label type tag que on aurait attaché sur un ensemble de wikitty ?
Comme déjà dit, la solution 2 est prévue dans l'API.
3) Concernant le numéro de version, il est incrémenté par le service wikitty, donc on peut comitter auprès d'un service wikitty si notre num de version locale est supérieur ou égale à celle du wikitty service ?
Dans SVN, ça pose pas de problème tant qu'il arrive à merger.
4) Dans le cas d'un update, j'update en écrasant ? Sans me soucier de ce qui est existant, ou je dois faire un diff, réécrire ce qui a été effacé ? Dans le premier cas ça revient à repartir comme si on faisait un checkout.
Dans SVN il fusionne, s'il y arrive pas il te propose une résolution de conflit. Écraser, ça me parait violent et ça rend le truc inutilisable vu que du coup, pour mettre à jour commiter, et au commit t'as risque de conflit, pour voir le conflit faut mettre à jour, la boucle est bouclée, en cas de conflit tu perds tout :-(.
5) Si localement l'utilisateur fait des suppressions, des ajouts, des modifs et qu'il veut commit je dois faire un diff et faire les opérations delete liés automatiquement ? ou l'utilisateur doit faire les deletes lui même ?
Dans SVN, faut delete (et ajouter d'ailleurs) à la main.
6) On stocke dans l'arborescence un fichier de propriétés avec l'adresse du service wikitty, on le stock où ? Admettons je checkout le label ponay récursivement, le fichier de propriété se retrouvera dans ponay ou dans le dossier contenant le dossier ponay ?
SVN place tout ça dans le dossier concerné, pas le parent.
7) On doit pouvoir avoir un service de wikitty pour les WikittyPubText et un autre WikittyPubData, peut-il avoir dans les WikittyPubText une référence vers un WikittyPubData ? et donc doit on gérer la conservation du lien en modifiant le WikittyPubText pour lui dire que le WikittyPubData est ailleurs ?
8) Dans le cas d'un commit d'un dossier qui n'a jamais été mis sur dans le wikitty service on doit passer obligatoirement une adresse de service, et après on fait comme télécharge les fichiers de propriété correspondant ? comme si on avait fait un checkout ? (la question se pose aussi pour un commit de quelque chose qui existait déja dans le wikitty, si on fait un update automatique après)
Pour moi, toutes ces questions que tu poses sont les problèmes typiques de la modification concurrente/distribuée d'un document. Et à chaque question, on a envie de répondre « bah, faire comme dans SVN ». Les solutions existent point du vue théorique (horloge de Lamport, etc.) et techniques : les outils gestion de code source ont déjà résolu, avec plus ou moins de succès ces problèmes et je pense que si on recode tout ça (merge de la question 5, résolution de conflits), on va surtout réinventer la roue carrée et t'en as pour des mois. Ou alors, j'ai loupé un truc. Tant que je suis, on parle de SVN parce que c'est ce qu'on utilise. Toutefois, il me semble que dans Wikitty, on veut pouvoir checkouter les trucs depuis une instance de WikittyPublication, les modifier et les pousser vers une autre instance. Ça, c'est de la décentralisation, à l'exact opposé de la gestion de version centralisée type CVS/SVN. Si c'est vers ça qu'il faut tendre, vaut mieux se pencher sur le fonctionnement de Git/Mercurial/Darcs : http://en.wikipedia.org/wiki/Category:Distributed_revision_control_systems Hélas, aucun en Java qu'on pourrait reprendre à ma connaissance.
9) Il y a une gestion de version des éléments, au niveau global comme révision ou chaque élément sauvegardé à son propre numéro de version ?
Dans CVS c'était la seconde solution, ça posait des tas de problèmes. Dans SVN ils ont choisis la première, t'as une révision pour l'ensemble des fichiers modifiés et tout le repo suit ce numéro de révision.
Voilà pour la première batterie de questions d'autre surement à suivre.
Voila un stagiaire qui communique bien. En gros, on devrait tourner à un mail de ce genre par semaine tout au long du stage :-) -- Brendan Le Ny <bleny@codelutin.com> Code Lutin Conseil & Développement Logiciel Libre +33 (0)2 40 50 29 28 http://codelutin.com