2011/4/2 Brendan Le Ny <bleny@codelutin.com>
J'approuve les remarques de Ben, surtout la récursion et effectivement, je
me demande si y'a pas une vrai différence entre répertoire et label et
d'après les cas d'utilisation que je vois, j'ai l'impression que les
répertoires suffisent. Tout comme dans svn on peut très bien checkouter
une sous-partie de l'arborescence. L'idée des label est qu'on pourrait
checkouter seulement une partie des données seulement ? genre un label
"truc" mais les wikitty labellisés truc se trouvent un peu partout dans
l'arbo et on ne prend que ceux-là ?


D'après ce que j'ai compris, les labels sont les dossiers finalement, leur nom permet de les situés dans l'arborescence, et c'est grâce donc à ces labels que l'on peut replacer les fichiers dans l'arborescence. Et ça explique pourquoi on fait la récursion sur les labels quand on veut checkout, commit, etc. Et pour checkout un label "truc" qui placerais des fichiers un peu partout, c'est ce que je pensais au départ mais on m'a dit que justement non, on a correspondance entre label et dossier finalement.


 
Je ne vois pas de différence entre import et commit. Comme j'ai l'ai dit,
vu l'aspect décentralié (relocate toussa), il faut plutôt coller aux
commandes des DVCS. D'ailleurs import, quand j'ai lu ce que ça faisait
j'avais pensé à import dans l'autre sens, "import" ne veut rien dire, la
question c'est de savoir qui importe/exporte. Un terme tel que "push"
serait plus adapté. Pour les commandes courantes, je reprendrais la liste
ici (init/clone/pull/push/checkout/update/commit etc.) :

http://en.wikipedia.org/wiki/Comparison_of_revision_control_software#Basic_Commands

Il manque le revert, indispensable :)

Le revert implique que on ait dans l'arborescence dans les fichiers caché une sauvegarde du contenu précédent, je veux bien, mais es ce que je vais pas réinventer la roue en refaisant un gestionnaire de version finalement ? En moins bien.
 

Quand tu add/delete, ça commit tout seul (mauvaise idée) où faut commiter
à la main derrière (bonne idée) ?

A priori le modèle de fonctionnement voulait que le add soit par défaut dans le commit, on add dans le wikittyservice tout ce qui à été rajouté dans le projet sans se poser de question. Le modèle de delete "commit" tout seul d'après le modèle. Le fait de pas commit directement impliquerait de mettre un "marqueur" dans le fichier de propriété pour qu'au commit le delete soit pris en compte, ça change pas mal de chose pour moi, à voir avec Benjamin comment il voit ça, et le modèle de fonctionnement qu'il souhaite.

Côté Wikitty Service, vu qu'on est en HTTP, on pourrait utiliser ces mots
comme verbes HTTP voire coller avec REST (on attend toujours une
présentation en réunion dev ;)).

Là, je passe.
 
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.
 
Le modèle de merge qu'on m'a proposé c'est de faire comme cvs, à coup de chevron pour noter les différences entre version locale et distante, faire un "vrai" système de merge je m'éloignerais un peu du sujet de base non ? Je passerais de wikittypublication à un gestionnaire de version en java sur wikitty.
 
Sinon, pinaillage mais "wp" je trouve ça vraiment trop nul comme nom. Déjà
ça évoque WordPress, WikiPédia ou  une commande native. Je préfèrerai
"wyp" ou "wypub".

J'ai pas d'avis sur la question.