je dirais plutôt un inconvénient selon moi, surtout si il y a plusieurs utilisateurs.
un wiki, c'est censé être modifié très souvent, le contenu bouge etc. Cela veut aussi dire qu'une modification dans une page = un commit (que ce soit dans un dépôt git ou un autre système d'archivage).
Résultat(1) : on se retrouve avec des centaines de commits (dont beaucoup ce sont des petites corrections d'orthographes ou autres). Et bien souvent, les utilisateurs ne mettent pas de "message de commit" (y compris moi, par flemme), donc on se retrouve avec des commits ayant le même intitulé par défaut.
Si le contenu du wiki est dans le même dépôt que le code source, on se retrouve alors avec un historique complètement illisible. Ce qui annihile tout intérêt de versionner le code source.
La documentation dans le même dépôt que le code source, pourquoi pas (je le fais bien pour slimerjs), mais faut pas que ce soit un wiki (c'est à dire, modifiable par une interface web). Et faut que ce soit une doc qui évolue en même temps que le code, donc très proche du code. Par exemple, une doc de référence (api etc) ok. Pour des tutoriaux ou manuels : je préfère un dépôt à part, car au final ils ont leur vie propre, et n'ont pas le même rythme de vie (par exemple, pour la documentation d'une lib, on va écrire les tutoriaux qu'une fois que l'api est relativement stable, et pas au fur et à mesure, sinon on risque de réécrire des parties du tuto 50 fois -> perte de temps).
(1) ceci est une constatation que je fais à partir de wikis que je possède ou possédait, ouvert à plusieurs personnes.
[^] # Re: Y'a plus simple
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal GitLab, mais encore ?. Évalué à 4.
je dirais plutôt un inconvénient selon moi, surtout si il y a plusieurs utilisateurs.
un wiki, c'est censé être modifié très souvent, le contenu bouge etc. Cela veut aussi dire qu'une modification dans une page = un commit (que ce soit dans un dépôt git ou un autre système d'archivage).
Résultat(1) : on se retrouve avec des centaines de commits (dont beaucoup ce sont des petites corrections d'orthographes ou autres). Et bien souvent, les utilisateurs ne mettent pas de "message de commit" (y compris moi, par flemme), donc on se retrouve avec des commits ayant le même intitulé par défaut.
Si le contenu du wiki est dans le même dépôt que le code source, on se retrouve alors avec un historique complètement illisible. Ce qui annihile tout intérêt de versionner le code source.
La documentation dans le même dépôt que le code source, pourquoi pas (je le fais bien pour slimerjs), mais faut pas que ce soit un wiki (c'est à dire, modifiable par une interface web). Et faut que ce soit une doc qui évolue en même temps que le code, donc très proche du code. Par exemple, une doc de référence (api etc) ok. Pour des tutoriaux ou manuels : je préfère un dépôt à part, car au final ils ont leur vie propre, et n'ont pas le même rythme de vie (par exemple, pour la documentation d'une lib, on va écrire les tutoriaux qu'une fois que l'api est relativement stable, et pas au fur et à mesure, sinon on risque de réécrire des parties du tuto 50 fois -> perte de temps).
(1) ceci est une constatation que je fais à partir de wikis que je possède ou possédait, ouvert à plusieurs personnes.