Veracity est un nouveau gestionnaire de versions décentralisé (DVCS), sous licence Apache. Il est développé en C par la société SourceGear, avec la possibilité d'embarquer des greffons en javascript.
Comparé à git ou mercurial, il essaye d'intégrer une expérience de développement plus large :
- interface web complète (vous pouvez voir à quoi elle ressemble en consultant le dépôt public de Veracity) ;
- flux d'activité ;
- suivi des bugs distribué ;
- graphe burndown.
Il est possible de l'installer sous GNU/Linux, Mac et Windows. Des paquets pour Ubuntu et un guide sont également disponibles pour vous aider à démarrer.
Aller plus loin
- Le site officiel de Veracity (1030 clics)
- Questions/réponses sur Veracity (307 clics)
- Le dépôt public de Veracity, qui tourne avec Veracity (206 clics)
- Annonce de Veracity 0.9.1 (62 clics)
- Liste des technologies utilisées dans Veracity (222 clics)
- La liste de diffusion de Veracity (48 clics)
# Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à -4.
Encore un logiciel écrit en C, avec apparemment beaucoup de réécriture : parseur/sérializeur JSON, vcdiff, leurs APIs portables...
Je leur souhaite bonne chance mais j'ai l'impression de voir toujours le même schéma, où une nouvelle équipe réinvente toutes les briques de base, dans un langage de bas niveau : je ne crois pas au résultat.
[^] # Re: Pourquoi C ?
Posté par Galou (site web personnel) . Évalué à 10.
Peut-être parce que c'est portable et que le principe de bibliothèque de fonctions existe aussi en C ?!!
[^] # Re: Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à 2.
D'accord, les bibliothèques de fonctions existent en C... Mais visiblement pour ce projet il est hors de question d'utiliser des bibliothèques solides écrites à l'extérieur, il faut tout réécrire par eux-même (et bien sûr le résultat sera forcément meilleure et plus robuste, hein ?).
[^] # Re: Pourquoi C ?
Posté par phoenix (site web personnel) . Évalué à 9.
Le C c'est bien. Je fais du dev en C/C++ et avec Qt. Le C n'a rien à envier aux autres langages, il y a des bibliothèque qui permettent de faire beaucoup de chose en C.
C'est quoi toutes cette animosité en faire ce langage ?
[^] # Re: Pourquoi C ?
Posté par Lutin . Évalué à 10.
Parce que pour la plupart des gens le précepte "ne pas réinventer la roue" consiste à pondre du framework de framework pour avoir un usine à gaz du type "python over java over erlang over ruby avec java over javascript". Ne reprendre qu'une manière de faire ou un algorithme pour le recoder à sa manière dans un langage avec lequel on est à l'aise serait réinventer ladite roue.
J'exagère, mais c'est l'impression que j'ai après de nombreuses lectures de forums sur le sujet du logiciel libre.
[^] # Re: Pourquoi C ?
Posté par Anonyme . Évalué à -1.
Bravo, premier message Internet que je lis dans ce sens.
En passant, ça doit expliquer en partie le réchauffement de la planète. -> []
[^] # Re: Pourquoi C ?
Posté par Mathias Bavay (site web personnel) . Évalué à 10.
Tout à fait d'accord... d'après mon expérience au boulot: nous avons deux modules logiciels qui se développent et sont maintenant très complémentaires. L'un (dont je m'occupe et dont j'ai fait quelques annonces ici) est sous forme d'une librairie C++, pour laquelle je passe mon temps a "réinventer la roue": je cherche les algorithmes standards pour un problème donné, puis je les réimplémente en C++. L'autre projet délègue à des librairies tierces dès que cela pourrait faire économiser 3 lignes de code (véridique!). Et évidement, ne "réinvente pas la roue"!
Au final, après deux ans et demi de développement intense (avec quelque chose comme 1.5 personnes à temps plein dessus), la librairie compile sous Linux, osX et Windows, sans aucunes dépendances obligatoires (certaines dépendances optionnelles peuvent ajouter des fonctionnalités, comme le support de plus de systèmes de coordonnées géographiques via libproj), je peux très facilement fournir des paquets pour toutes ces plateformes, qui s'installent sans problèmes, et bonus supplémentaire, les fonctionnalités offertes par la bibliothèque sont cohérentes et suivent la même logique.
Du coté du projet qui ne réinvente pas la roue, les dépendances multiples sont tellement simple à gérer que mettre à jour vers une version plus récente avait pris (la dernière fois que je l'avais fait) 3 jours à 3 personnes (dont 2 des développeurs du projet). Et ils voudraient maintenant distribuer une image de machine virtuelle afin de rendre "l'installation" plus aisée... Et il ne faut pas oublier le temps passé à débugguer les questions d'intégration, les changements dans les multiples librairies externes, etc. Donc on final, on obtient un monstre pas portable, indéployable, dont le moindre ajout de fonctionnalité demande beaucoup de temps et qui n'a pas de cohérence interne...
Alors si réimplémenter des algos standards pour les intégrer dans un projet c'est "réinventer la roue", je préfère réinventer la roue...
[^] # Re: Pourquoi C ?
Posté par sifu . Évalué à 7.
Après cela dépend ce qu'on appelle réinventer la roue ...
J'ai vu pleins de développeurs refaire des parsers HTML.
Pour moi l'une des forces de l'open source, c'est justement la possibilité d'utiliser des librairies et d'y contribuer plutôt que de refaire un truc dans son coin.
C'est vrai que certains langages facilitent pas mal de travail, je pense notamment au gem, PIP, PEAR, CPAN, Maven ou encore NuGet.
[^] # Re: Pourquoi C ?
Posté par fmaz fmaz . Évalué à 0.
De mon point de vue, tu ne réinventes pas la roue.
Tu fais de la biblio pour voir ce qui existe (et ne pas réinventer la roue). J'imagine qu'au cours de ce processus, tu trouves plusieurs solutions algorithmiques possibles et tu choisis celle qui te semble la plus adaptée à ton problème.
Réinventer la roue, c'est ne pas regarder ce qui existe déjà et implémenter une solution non optimale alors qu'avec un peu d'effort, on se serait rendu compte qu'il existe un truc plus efficace, pas plus compliqué, voir même simplement juste.
[^] # Re: Pourquoi C ?
Posté par Anonyme . Évalué à 2.
Pour appuyer le point de vue de Mathias lisez Méthodes de génie logiciel avec Ada - Composants logiciels. J'en conclue que comme toute bonne chose il ne faut pas abuser du précepte « Tu ne réinventeras pas la roue ». La réutilisation a un sens au sein d'un ensemble de logiciel développés conjointement comme par exemple : KDE, Gnome, les utilitaires Unix. Chaque équipe doit développer ses propres composants.
Au sein d'une distribution faite de milliers de logiciels disparates la source de réutilisation se trouve dans la philosophie Unix de découpage des fonctionnalités en utilitaires distinctes.
[^] # Re: Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à -6.
Ok, et tu as essayé quelques autres langages moderne de haut-niveau (Go, OCaml, Haskell, Clojure, Scala...) ? Parce que dire que C/C++ c'est bien après avoir essayé C, C++, un peu de Java et une touche de Python, ça n'est pas des plus convaincant. C a sa place, pour écrire des bibliothèques robustes et performantes de base ; pour ce qui est d'une application complexe avec un cœur algorithmique important, communicant avec l'extérieur et une grande importance de la sûreté d'exécution, je crois que C n'est plus depuis longtemps le bon choix.
[^] # Re: Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à -7.
Ok, pour être plus précis, C c'est bien pour certains domaines, ce que je conteste (et qui est objectivement faux) c'est l'affirmation que : "Le C n'a rien à envier aux autres langages".
Le C est un langage de bas niveau avec un système de type assez faible et peu expressif, très fragile, offrant d'innombrable occasions d'être exploité, n'offre que peu d'options pour gérer la mémoire automatiquement (pas forcément un GC mais même les capacités de C++ sont très supérieures à cet égard), sa syntaxe est restrictive et les capacités d'abstractions sont très limitées.
[^] # Re: Pourquoi C ?
Posté par Zenitram (site web personnel) . Évalué à 9.
Tiens, c'est exactement ce que je me dis sur Python, Ruby, Java... Tu n'aurais pas un problème de chronologie sur qui réinvente la roue?
[^] # Re: Pourquoi C ?
Posté par monde_de_merde . Évalué à 10.
Oui tu as raison, on aurait du en rester au Fortran il y a bien des années. C'est quoi cette manie d'inventer de nouveaux langages toutes les 5 minutes ?
C'était mieux à vent.
[^] # Re: Pourquoi C ?
Posté par collinm (site web personnel) . Évalué à 8.
comme linux quoi...
www.solutions-norenda.com
[^] # Re: Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à 5.
Créer un nouveau langage de programmation n'est pas exactement la même chose que coder une nouvelle application...
[^] # Re: Pourquoi C ?
Posté par Matthieu Moy (site web personnel) . Évalué à 10.
La démarche est discutable, mais ça n'empêche pas forcément le projet d'aboutir. Git a une bonne dose de « réinvention de la roue » (moteur de diff, parseur d'options en ligne de commande parse_option, bibliothèque de manipulation de chaînes strbuff, ...), mais une bonne partie des roues réinventées par Git sont de bonne qualité, et le fait de les avoir inclus dans le code de Git fait qu'il est relativement simple de recompiler Git soi-même (j'ai déjà essayé de recompiler une vieille version de SVN, il fallait plus ou moins recompiler tout Apache avec, c'était pas une partie de plaisir).
Si c'était moi qui avait écrit Git, je n'aurais sans doute pas fait comme ça, mais je suis bien obligé d'admettre que le résultat reste bon (et je ne suis pas le seul à apprécier Git je crois ;-) ).
Maintenant, est-ce que veracity réussira à se faire une place à côté de solutions relativement bien établies comme Git et Mercurial, ça reste à voir ...
[^] # Re: Pourquoi C ?
Posté par mr_spoke . Évalué à 2.
Quand git et mercurial sont arrivé, ils ont réussi non seulement à se faire une place à côté de solutions relativement bien établies comme subversion, mais ont fini par le détrôner.
[^] # Re: Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à 3.
Néanmoins Git n'essayait pas de s'imposer dans un champ où il y avait déjà un leader fort, Subversion n'est pas un DVCS et continue à être utilisé dans bien des cas où le modèle centralisé a ses mérites. Les concurrents de Git (dont Mercurial, darcs, Bazaar...) avaient montré que les DVCS avaient d'intéressants avantage mais aucun ne s'était imposé comme Git l'a fait : le paysage des DVCS est maintenant franchement dominé par Git (je ne dis pas que les autres ont disparu) et Veracity rentre en retard sur le champ de bataille. Le choix du C et d'une approche de réimplémentation indépendante de toutes les parties de l'application ne me semble pas judicieux dans ce cadre, Veracity n'a pas une communauté derrière elle de la même ampleur que celle soutenant git.
[^] # Re: Pourquoi C ?
Posté par Littleboy . Évalué à 9.
Dans le monde du libre, en majorite oui. Par contre, en entreprise...
La cible n'est pas du tout la meme, Veracity c'est clairement prevu pour les entreprises (d'une taille assez importante) pour remplacer du SourceSafe ou du Subversion. A partir de la, les fonctionnalites importantes ne sont pas les memes et le gros du dev et du support sera sur les besoins qu'ont les grosses structures (en particulier en terme de suivi de projet et de gestion des droits utilisateurs).
Vu le support merdique de git sur leur principale plateforme cible (Windows) on va dire qu'ils ont toutes leurs chances (le leader du port Windows qui dit a plusieurs reprises que la majorite des programmeurs Windows sont des gros cons sur la mailing list du projet, ca donne vraiment confiance aux decideurs en entreprise).
Il faut pas se tromper, leurs concurrents c'est Fogbugz + Kiln (base sur Mercurial), Perforce et Subversion (la version avec support par Collabnet), le reste ca serait sympa de faire pas trop mal en face, mais c'est pas de la que vont venir leurs revenus.
[^] # Re: Pourquoi C ?
Posté par 2PetitsVerres . Évalué à 10.
Ben quoi, ils n'aiment pas l'honnêteté ? /o\
Tous les nombres premiers sont impairs, sauf un. Tous les nombres premiers sont impairs, sauf deux.
[^] # Re: Pourquoi C ?
Posté par Antoine . Évalué à 2.
Seulement pendant les conseils d'administration.
[^] # Re: Pourquoi C ?
Posté par zebra3 . Évalué à 1.
Ben c'est vrai, sinon ils développeraient pour Linux et/ou BSD.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Pourquoi C ?
Posté par Chaddaï Fouché . Évalué à 4.
Bien sûr ça fait penser à git et on ne peut pas dénier que git soit maintenant un énorme succès (à l'échelle des VCS en tout cas) mais il faut tout de même voir que git avait derrière lui tout le poids de Linus et bien vite d'une bonne part de la communauté de développement du noyau, bon nombre de développeurs d'exception habitués à travailler vite et bien et en C (ce qui rendait le choix du langage assez évident !). Et même git n'était pas aussi ambitieux que semble l’être ce nouveau projet.
[^] # Re: Pourquoi C ?
Posté par tyoup . Évalué à -1.
beurk !! quoi de pire dans un programme que d'avoir une dépendance ?? ça génère des conflits, il faut faire attention aux mises à jour de sécurité, tout casser à chaque fois en rajoutant des bugs, c'est tout sauf passionnant, il faut synchroniser les mises à jour des composants partagés, il faut apprendre le fonctionnement, trouver la doc qui n'existe pas, tâtonner, contourner les limitations et les anomalies... fiou que de contraintes, vive le logiciel LIBRE !
[^] # Re: Pourquoi C ?
Posté par zebra3 . Évalué à 2.
Euh justement, c'est pas le rôle des distributions ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Pourquoi C ?
Posté par zebra3 . Évalué à 10.
C'est sûr, il y a beaucoup plus de système Linux installés à la main qu'en utilisant une distribution…
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# fossil
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 5.
Cet outil me fait beaucoup penser à fossil.
Reste à fouiller pour comprendre ce qu'il a de différent et pourquoi il faudrait l'utiliser plutôt que les autres.
http://fossil-scm.org/
# javascript
Posté par manawy (site web personnel) . Évalué à 4.
et il n'y aurait pas une interface web sans les effets qui servent à rien ? ça simplifie pas vraiment les choses...
[^] # Re: javascript
Posté par mickabouille . Évalué à 2.
J'ai l'impression que c'est les plugins qui sont en javascript, c'est à dire que JS sert de langage d'extension, pas que l'interface web utilise du JS. JS ne sert pas que dans un navigateur mais aussi en "server side JS", comme langage d'extension pour des applications ordinaires (Gecko, et si j'ai bien compris le shell gnome).
# Le guide est un peu léger ...
Posté par sifu . Évalué à 3.
Le guide est un peu léger et on ne voit pas trop ce qu'apporte Veracity aux autres DVCS.
Les deux fonctionnalités qui pourraient différencier Veracity des autres ne sont pas mis en avant.
Par exemple, pour le "burndown chart", on c'est pas trop sur quoi cela repose ...
# Par rapport à d'autres ?
Posté par Guillaume Camera . Évalué à 5.
Et concrètement, par rapport à un couple redmine/git, qu'est-ce que ça apporte ? Peut-être quelque chose de plus centraliser pour une admin simplifiée, mais d'un point de vue utilisateur ? (Une question surement idiote, mais je n'ai rien trouvé de très concret à ce sujet sur la présentation/doc)
[^] # Re: Par rapport à d'autres ?
Posté par vlad59 (site web personnel) . Évalué à 2.
Je me pose la même question : à part ajouter des fonctionnalités auparavant liées à bugzilla/mantis/trac/redmine je ne vois pas trop l'intérêt.
Surtout qu'entre git, mercurial et bazaar c'était déjà un peu la bazar (uh uh uh).
[^] # Re: Par rapport à d'autres ?
Posté par sifu . Évalué à 2.
Effectivement, on peut se poser la question et le site n'est pas très riche en informations.
Personnellement, vu le peu d'informations fournies, j'ai pas tellement envie d'y aller ...
C'est déjà dur de mettre en place un DVCS reconnu car il ne s’intègre pas forcément à l'écosystème en place.
[^] # Re: Par rapport à d'autres ?
Posté par fredix . Évalué à 3.
En même temps s'il fallait à chaque fois choisir un outil qui s'intègre à l'existant, ce qui veut dire ne pas vouloir faire d'effort pour changer ses habitudes, on serait resté à CVS ...
[^] # Re: Par rapport à d'autres ?
Posté par Guillaume Camera . Évalué à 2.
Certes, mais on est d'accord que Git a quand même de nombreux intérêts face à CVS. D'où l'effort pour changer. Là concrètement.. je vois pas trop.
[^] # Re: Par rapport à d'autres ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 10.
Je sais pas ce qu'il vous faut mais moi je trouve que l'idée d'intégrer le bug tracking directement dans le VCS, je trouve ça génial. Chaque branche embarque donc en elle-même ses résolutions de bugs, les commentaires liés aux bugs, bref, le réel historique du projet.
Moi, je suis fan de l'idée!
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Par rapport à d'autres ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
fossil scm le fait déjà et on ne voit pas trop ce que ce nouveau VCS apporte.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Par rapport à d'autres ?
Posté par sifu . Évalué à 3.
A priori, je suis pas fan de l'idée.
Pour moi, le BT et VCS ne s'adressent pas forcément au même public. Le BT a souvent un workflow bien différent.
Autant, je trouve cela intéressant de pouvoir lié les deux autant je trouve que fusionner les deux outils n'est pas forcément pertinent.
[^] # Re: Par rapport à d'autres ?
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Pour les petits projets, c'est très utile. Avec fossil (et je suppose avec ce nouveau VCS), ça prends 5min de monter un dépôt, un bug tracker et un wiki qui sert de site du projet.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Par rapport à d'autres ?
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
peut-être que oui, peut-être que non :-)
J'avoue que je ne sais pas trop. Jusqu'à la lecture de cette news, c'est une idée qui ne m'avais jamais effleuré et que, à première vue, je trouve géniale.
Après, je n'ai pas poussé l'analyse beaucoup plus loin non plus. Je trouve que lié les deux pourrait peut-être faciliter la transition entre les "bug reporters" et les contributeurs de code. Mais je n'en sait rien hein. Faudrait tester.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: Par rapport à d'autres ?
Posté par zebra3 . Évalué à 6.
On voit que tu es belge, on croirait lire Copiepresse : « Hé les gars, j'ai une idée géniale, on va faire payer Google ! »
;-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Par rapport à d'autres ?
Posté par CrEv (site web personnel) . Évalué à 4.
Ha ben c'est sur, si ton serveur de source n'est pas lisible par ton serveur de build / d'intégration c'est pas grave.
Si ton bug tracker ne peut pas lire les commits, c'est pas grave non plus.
Si ton IDE ne peut pas le gérer, c'est pas important non plus.
Mouai... Dans le vrai monde il faut que ça s'intègre un minimum. Ca ne veut pas dire qu'il faut pouvoir remplacer à l'identique l'ancien par le nouveau, mais il faut que les outils puissent quand même communiquer un minimum, et ce n'est pas "ne pas vouloir faire d'effort pour changer ses habitudes".
Après, si l'outil est bon alors les modifications concernant les autres arriveront, mais quand le vois le temps qu'il faut pour avoir des plugins mercurial / git correct ... ben c'est pas facile pour les nouveaux.
C'est vrai, lorsqu'on change de système de source on prévoit en même temps de changer l'intégralité des outils existant, on les met à la poubelle et on en développe des nouveaux.
[^] # Re: Par rapport à d'autres ?
Posté par fredix . Évalué à 0.
Bin l'effort serait de changer de bug tracker ou d'IDE. Après c'est sur que cela peut être une contrainte pas possible à gérer en entreprise par exemple.
[^] # Re: Par rapport à d'autres ?
Posté par CrEv (site web personnel) . Évalué à 4.
Mais c'est ni une question d'effort, ni d'entreprise.
A moins d'utiliser un IDE qui ne fait rien, je connais très peu de personnes qui se disent "tiens, si je changeais d'IDE"
Un IDE est choisi en général pour ses fonctionnalités d'édition de code (refactoring, toussa). Ensuite on regarde les connecteurs.
Mais dire "tiens on va changer de gestionnaire de source, développeurs il faudrait faire l'effort de changer d'IDE" je pense que c'est juste être loin de la réalité...
[^] # Re: Par rapport à d'autres ?
Posté par fredix . Évalué à -1.
Donc dans ta réalité personne utilise Emacs ? :)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Par rapport à d'autres ?
Posté par CrEv (site web personnel) . Évalué à 5.
J'attendais un truc du genre...
Donc :
Dans un contexte d'entreprise (mais pas que hein) c'est évidemment in-envisageable de dire "c'est parce qu'ils ne veulent pas faire l'effort" s'ils ne veulent pas changer d'ide juste pour utiliser un autre gestionnaire de source. Le gestionnaire de source n'est au final qu'un outil et il ne doit pas impacter les autres outils mais discuter avec.
# Petite bafouille complémentaire
Posté par El Titi . É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.
[^] # Re: Petite bafouille complémentaire
Posté par El Titi . Évalué à 2.
Pour les anglophiles
http://www.infoq.com/news/2011/07/Veracity
[^] # Re: Petite bafouille complémentaire
Posté par FreeB5D . Évalué à -1.
Foutaises !
[^] # Re: Petite bafouille complémentaire
Posté par El Titi . Évalué à -2.
Le business loto (buzzword bingo aux États-Unis ...
http://fr.wikipedia.org/wiki/Business_loto
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.