Comme ca fait un petit moment que je suis ce projet et que j'envisageais de le présenter par ici, je vais essayer d'apporter quelques infos et répondre à certaine des questions qui ont été posées.
L'auteur, d'abord:
Erik Sink n'est pas un nouveau venu dans la gestion de conf car il est l'auteur d'un outil de gestion de version centralisé et proprio assez connu dans le monde Windows qui a fait de l'ombre au triste Visual Source Safe (pas dur, je sais): Vault http://en.wikipedia.org/wiki/Vault_(revision_control_system)
Pourquoi un autre VCS ?
Comme Erik l'indique ici http://www.ericsink.com/entries/veracity_early.html, sa motivation première est de coller aux besoins des entreprises (contrôle des accès aux sources, architecture standardisée, ...) qui plébiscitent souvent une approche centralisée là où les DVCS se concentrent avant tout sur les besoins de communauté éparses et plus ouvertes aux nouvelles contributions.
On a donc la licence déjà: Apache (même si la réticence à la GPL est bien souvent irrationnelle)
Chapeau bas pour un editeur de logiciel proprio.
Ensuite le fait de concilier approche centralisée et distribuée.
Oui on peut bosser en centralisé avec Git et Hg, sauf que pas moyen de locker un fichier lorsque c'est nécessaire (artwork, fichier binaires, ...) et il est toujours nécessaire de se créer une branche locale et passer par le commit+push alors que le simple commit
Le seul qui s'y essaye c'est Bazaar avec ses branches partagées, mais il ne propose pas le verrou pessimiste je crois.
En plus, il n'intègre pas de notion de work item et de bugtracker.
Le stockage se fait en DB (sqlite) plutôt que par fichier.
Ce choix est discutable à priori mais est rassurant pour les admins (cluster/replication,...), même si Github
est un contre exemple flagrant (ok pour répartir les dépôts sur n serveurs mais quid des reposistory gargantuesques)
Au niveau du rename tracking, le choix de gérer les repertoires en conf et d'historiser les renommages/déplacements de fichier comme Bazaar plutôt que de le deviner (Git) est securisant. Quiconque s'est confronté à un refactoring entre 2 branches sous SVN comprendra.
Par contre en faisant correspondre explicitement des arborescences comme le fait Perforce cet avantage n'est pas si important http://web.archive.org/web/20100102124647/http://perforce.com/perforce/papers/branch.html
Veracity se distingue des DVCS classiques en intégrant des fonctionnalité de bugtracking: les working items font partie intégrante de l'outil.
Comme Clearcase/UCM avec ses "activities" ou Perforce, ceci permet de coupler leur traitement à l'outil plutôt que de recourir à des artifices (no de bug dans le commentaire du commit).On peut donc les manipuler directement (report de plusieurs commit associés à une work item plutôt que d'amender les commit, hooks, ...)
Le fait que le bugtracker soit distribué peut apparaitre comme un avantage: On résoud un bug et on commite le code dans la même transaction. Mais ceci ne peut pas être complètement ditribué car à un moment donné l'aspect centralisé est important pour communiquer, sinon 2 personnes risquent de corriger le même pb sans se consulter.
Sur ce point il est comparable à fossil-scm qui laisse quant à lui sur sa faim au niveau de ses qualités de VCS (Veracity devra faire ses preuves) et qui reste un bugtracker très moyen.
Enfin Veracity offre des facilités au niveau l'integration continue, de la gestion de projet (Scrum burndown), une API REST, JSON ... que des buzzwords daicideur friendly.
Sur ce point, il ambitionne de se mesurer aux pointures de l'ALM et je ne serais pas mécontent de voir apparaître un véritable challenger open source à la plateforme Jazz/Rational Team Concert d'IBM qui a gardé une API et des spec ouvertes tout en conservant le code fermé. (le fameux modèle open commercial: testez, faites des specs, des passerelles mais nous on garde not business)
Bref, vous l'aurez compris je suis impatient de voir ce que la 1.0 prévue pour le prochain OSCON (fin juillet) aura dans le ventre.
# Petite bafouille complémentaire
Posté par El Titi . En réponse à la dépêche Veracity, un nouveau gestionnaire de versions décentralisé. Évalué à 10.
Comme ca fait un petit moment que je suis ce projet et que j'envisageais de le présenter par ici, je vais essayer d'apporter quelques infos et répondre à certaine des questions qui ont été posées.
L'auteur, d'abord:
Erik Sink n'est pas un nouveau venu dans la gestion de conf car il est l'auteur d'un outil de gestion de version centralisé et proprio assez connu dans le monde Windows qui a fait de l'ombre au triste Visual Source Safe (pas dur, je sais): Vault http://en.wikipedia.org/wiki/Vault_(revision_control_system)
Je vous recommande la lecture de son blog et notamment une série d'articles intéressants sur la gestion de conf
http://www.ericsink.com/scm/source_control.html. Cet hyperactif nous prépare même un bouquin sur le topic que je suis impatient de potasser:
http://www.ericsink.com/entries/book2_reviewers_needed.html
Veracity:
Pourquoi un autre VCS ?
Comme Erik l'indique ici http://www.ericsink.com/entries/veracity_early.html, sa motivation première est de coller aux besoins des entreprises (contrôle des accès aux sources, architecture standardisée, ...) qui plébiscitent souvent une approche centralisée là où les DVCS se concentrent avant tout sur les besoins de communauté éparses et plus ouvertes aux nouvelles contributions.
On a donc la licence déjà: Apache (même si la réticence à la GPL est bien souvent irrationnelle)
Chapeau bas pour un editeur de logiciel proprio.
Ensuite le fait de concilier approche centralisée et distribuée.
Oui on peut bosser en centralisé avec Git et Hg, sauf que pas moyen de locker un fichier lorsque c'est nécessaire (artwork, fichier binaires, ...) et il est toujours nécessaire de se créer une branche locale et passer par le commit+push alors que le simple commit
Le seul qui s'y essaye c'est Bazaar avec ses branches partagées, mais il ne propose pas le verrou pessimiste je crois.
En plus, il n'intègre pas de notion de work item et de bugtracker.
Le stockage se fait en DB (sqlite) plutôt que par fichier.
Ce choix est discutable à priori mais est rassurant pour les admins (cluster/replication,...), même si Github
est un contre exemple flagrant (ok pour répartir les dépôts sur n serveurs mais quid des reposistory gargantuesques)
Au niveau du rename tracking, le choix de gérer les repertoires en conf et d'historiser les renommages/déplacements de fichier comme Bazaar plutôt que de le deviner (Git) est securisant. Quiconque s'est confronté à un refactoring entre 2 branches sous SVN comprendra.
Par contre en faisant correspondre explicitement des arborescences comme le fait Perforce cet avantage n'est pas si important
http://web.archive.org/web/20100102124647/http://perforce.com/perforce/papers/branch.html
Veracity se distingue des DVCS classiques en intégrant des fonctionnalité de bugtracking: les working items font partie intégrante de l'outil.
Comme Clearcase/UCM avec ses "activities" ou Perforce, ceci permet de coupler leur traitement à l'outil plutôt que de recourir à des artifices (no de bug dans le commentaire du commit).On peut donc les manipuler directement (report de plusieurs commit associés à une work item plutôt que d'amender les commit, hooks, ...)
Le fait que le bugtracker soit distribué peut apparaitre comme un avantage: On résoud un bug et on commite le code dans la même transaction. Mais ceci ne peut pas être complètement ditribué car à un moment donné l'aspect centralisé est important pour communiquer, sinon 2 personnes risquent de corriger le même pb sans se consulter.
Sur ce point il est comparable à fossil-scm qui laisse quant à lui sur sa faim au niveau de ses qualités de VCS (Veracity devra faire ses preuves) et qui reste un bugtracker très moyen.
Enfin Veracity offre des facilités au niveau l'integration continue, de la gestion de projet (Scrum burndown), une API REST, JSON ... que des buzzwords daicideur friendly.
Sur ce point, il ambitionne de se mesurer aux pointures de l'ALM et je ne serais pas mécontent de voir apparaître un véritable challenger open source à la plateforme Jazz/Rational Team Concert d'IBM qui a gardé une API et des spec ouvertes tout en conservant le code fermé. (le fameux modèle open commercial: testez, faites des specs, des passerelles mais nous on garde not business)
Bref, vous l'aurez compris je suis impatient de voir ce que la 1.0 prévue pour le prochain OSCON (fin juillet) aura dans le ventre.