Questions wikitty publication sync
Bonjour, J'ai quelques questions sur la première partie(commit/udpate/delete/ checkout) de wikitty publication dont je dois m'occuper. 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] ? 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 ? 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 ? 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. 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 ? 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 ? 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) 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 ? Pour changer de wikiservice cible se pose la question puisque le wikitty original n'a peut être pas la même version ? Voilà pour la première batterie de questions d'autre surement à suivre. Manoël
Le 30/03/2011 14:12, Manoël a écrit :
Bonjour,
J'ai quelques questions sur la première partie(commit/udpate/delete/ checkout) de wikitty publication dont je dois m'occuper.
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] ?
plutot svn non ? Mais oui, pour moi c'est l'idée
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 ?
De type tag. En fait tu as dans l'API une entité WikittyLabel que tu peux attacher a des wikittys, comme un tag.
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 ?
Supérieure strictement. En gros si c'est en version 4 sur le service et que tu commites en version 4 (ou moins), tu dois avoir une exception (Your wikitty is obsolete)
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.
Pour moi l'idéal c'est un diff, mais faut peut-être partir sur simple d'abord (checkout) et voir après pour le diff
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 ?
Pour moi c'est à toi de faire les deletes
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 ?
Le plus simple à gérer ?
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 ?
Euh là je passe mon tour, je peux ?
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)
Tu peux peut-être le générer pour éviter de le télécharger.
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 ?
Chaque élément a sa version actuellement
Pour changer de wikiservice cible se pose la question puisque le wikitty original n'a peut être pas la même version ?
Peut-être prévoir une option pour forcer la version. Bon des réponses succintes, j'espère pas trop pourries :D. Jean
On Wed, 30 Mar 2011 14:56:51 +0200 Jean Couteau <couteau@codelutin.com> wrote:
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)
Tu peux peut-être le générer pour éviter de le télécharger.
Si c'est un nouveau répertoire dans une arbo d'un projet déjà en lien avec un WikittyService, il faut récupérer le service utilisé Si c'est un nouveau projet pas encore en lien avec un wikitty service alors c'est la commande "import" qui doit être utilisée avec forcément l'adresse du wikitty service. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Wed, 30 Mar 2011 14:56:51 +0200 Jean Couteau <couteau@codelutin.com> wrote:
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 ?
Euh là je passe mon tour, je peux ?
Tu confonds les WikittyPubData avec les data (données) des applications. Les WikittyPubText et WikittyPubData sont toujours au même endroit. Par contre les données peuvent provenir d'un autre WikittyService -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
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
participants (4)
-
Benjamin POUSSIN -
Brendan Le Ny -
Jean Couteau -
Manoël