Hello,
Je découvre Bazaar qui est un gestionnaire de versions décentralisé. ( http://bazaar-vcs.org/ )
L'avantage du développement décentralisé m'apparaît comme évident dans le cadre de projets open-source ouverts à tous. N'importe qui peut en effet créer facilement sa propre branche et envoyer des patchs qui seront facilement "mergeable", même sans avoir reçu d'autorisation spéciale. Bzr présente également quelques outils qui ont l'air vraiment bien comme http://bundlebuggy.aaronbentley.com
Cependant, en grand utilisateur de SVN, j'ai du mal à voir l'avantage de Bzr dans les cas de figure suivants.
1) Mon répertoire personnel. Mes documents importants sont versionnés via SVN. De cette manière, j'ai un backup (vu que le dépôt SVN est sur un serveur distant) et un historique de mes documents (via une interface Trac). Les documents sont en majorité du texte et pas mal de fichiers binaires (documents openoffice). Je suis le seul à utiliser ce dépôt.
Les inconvénients de cette solution sont qu'il est très facile de foutre le bordel dans un checkout local svn (le plus souvant car manipulation des fichiers sans passer par les commandes SVN), rendant les commits parfois difficiles. L'autre inconvénient est qu'il n'existe pas d'outil permettant une vraie intégration de svn avec le système de fichier. (sous Windows, il y a tortoise)
Quel serait mon avantage à utiliser Bzr ?
2) Gestion de fichiers entre plusieurs personnes. Au boulot, on utilise des dépôts svn pour sauvegarder et partager des documents qui ne sont pas du code. Svn est un moyen de backup/restauration et aussi une manière d'être sur que tout le monde a toujours la dernière version.
Les inconvénients de cette solution sont qu'il est très facile de foutre le bordel dans un checkout local svn (le plus souvant car manipulation des fichiers sans passer par les commandes SVN), rendant les commits parfois difficiles.
Quel serait notre avantage à utiliser Bzr ?
3) Gestion d'un gros projet centralisé. Un gros projet fermé contenant, pour l'exemple, 2Go de code source. Le workflow habituel est que chaque développeur crée une branche svn avant de travailler sur un truc bien spécifique. Puis il merge. Le projet est développé en interne, sur un serveur interne, pas des gens directement connectés dessus. La décentralisation ne semble donc pas très utile à première vue.
Les inconvénients sont que les opérations peuvent parfois être très lentes (grosse source) et certains merge fastidieux.
Quel serait notre avantage à utiliser Bzr dans ce cas-ci ?
* * * * *
Bref, je suis curieux de tout retour d'expérience d'ancien utilisateur de svn qui sont passés à Bzr. Particulièrement les admins serveurs (j'ai personnellement mon serveur svn+http+ldap qui fonctionne très bien donc j'ai un peu de mal à imaginer devoir refaire tout ça).
Je me pose plein de questions, je suis en plein doute...
Bonus point : même questions mais pour Git cette fois (ou tout autre DVCS de votre choix)
Merci d'avance
Journal Migrer de Svn vers Bzr ?
31
août
2008
# svnfs
Posté par Pinaraf . Évalué à 8.
Hum, svnfs pourrait t'aider non ?
http://www.jmadden.eu/index.php/svnfs/
[^] # Re: svnfs
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
Mes livres CC By-SA : https://ploum.net/livres.html
# Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: svn, git
Posté par ploum (site web personnel, Mastodon) . Évalué à 2.
En fait, ma préférence va à Bzr par rapport à Git car il semble plus simple à utiliser et parce que je connais deux projets qui l'utilisent (Elisa et Pyroom). C'est de là qu'est venu mon besoin de me mettre à bzr. Je n'ai pas encore eu le besoin pour Git.
PS : mon rétablissement va très bien, je dois juste pas mettre mes bras au soleil ce qui est un peu pénible.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: svn, git
Posté par Stephane Wirtel (site web personnel) . Évalué à -1.
Launchpad et OpenERP
[^] # Re: svn, git
Posté par Damien Thébault . Évalué à 2.
Pour moi, les ajouts à l'index peuvent être remplacés par des vrais commits dans bzr. Les branches de git sont remplacées par des branches + un repository dans bzr.
Les fonctionnalité comme "bisect" ou "rebase" sont disponible dans bzr aussi (avec des plugins).
En fait, le système de plugins dans bzr est vraiment développé, et il en existe un grand nombre [1].
En ce qui concerne les performances, le problème principal que je vois à bzr, c'est le temps de lancement de python, mais avec bzr-shell (dans bzrtools [2]) il n'y a du coup plus de problème, c'est rapide.
J'ai pas mal utilisé svn avant, et bzr ressemble beaucoup à svn sur pas mal de points, notamment de la simplicité, et les commandes sont à peu près similaires.
[1] http://bazaar-vcs.org/BzrPlugins
[2] http://bazaar-vcs.org/BzrTools
[^] # Re: svn, git
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
> c'est le temps de lancement de python,
Malheureusement, sur des projets avec un historique un peu long, ce n'est pas le seul. Voir par exemple :
https://lists.ubuntu.com/archives/bazaar/2008q1/039273.html
Sur le repository d'Emacs, un "git log" complet met 5 secondes, alors que "bzr log" sur les 10 dernières révisions prends déjà plus de 2 minutes. Idem pour commiter : en général, "bzr status" est rapide, mais "bzr commit" est affreusement lent même en local. "git commit" est quasi-instantané sur tous les projets sur lesquels je l'ai essayé.
# backup et versionning
Posté par or zax . Évalué à 1.
Sinon l'intérêt de n'importe quel dvcs à svn c'est la gestion des branches, qui ne se limite pas à un synonme du terme dossier
# SVN c'est has been :)
Posté par Temsa (site web personnel) . Évalué à 10.
Pourquoi passer à autre chose que SVN ?
- SVN n'aime pas les refactorings de répertoire. Mine de rien, c'est facilement handicapant.
- la gestion des branches de SVN, et particulièrement les rennommages / déplacements / compléments de fichiers déplacé est minable (meme le red book SVN le dit)
- si tu veux disons garder tes confs synchro entre 2 ordi avec quelques petites différences dedans (genre la conf spécifique à une machine), t'aura du mal avec SVN.
- supporte mal les fichiers binaires
Alors j'ai bien aimé Bazaar au début, mais dans le cadre dans le quel je souhaitai bosser, en cross platform, bzr était mauvais (la version Windows est bof, l'intégration des plugin doit passer par la version "python", c'est vite le bordel à gérer, notamment le plugin d'interaction avec SVN, car il faut aussi un SVN patché).
Du coup Git est pas mal car très fourni, mais windows (et sans doute Mac aussi) reste(nt) un(^Wdes) citoyen(s) de seconde zone dessus et en dehors de l'interface fournie avec l'install(qui se cable un peu comme un "tortoisegit" dans l'explorateur), il n'y a pratiquement aucune intégration avec ce DVCS sous Windows.
Et la j'ai decouvert Mercurial, un vrai bonheur :) plus rapide que Bazaar, très fourni en plugins, choisi par Mozilla et Sun pour gérer d'énormes soft multi-plateforme, il tourne aussi bien sous Linux que sous Windows, s'intègre autant dans l'Explorateur que dans Nautilus que dans Maven que dans Eclipse que dans Netbeans (le gros de mon développement se fait en Java et Javascript, ces IDE conviennent parfaitement), import facile et rapide d'un repo SVN en gardant l'historique, il gère aussi les delta sur les fichiers binaires (je crois que Bzr et Git aussi, mais je ne suis pas sur), et les push/pull sont étonnament rapide (moins que git parait il, mais rien à voir avec Bzr ou SVN).
Pour un projet opensource, un DVCS c'est aussi : une facilité pour les nouveaux venu à proposer et maintenir des patch très facilement, à plusieurs même. C'est l'assurance d'avoir des merges bien foutus ( honnêtement le déplacement + renommage + ajout de contenu fonctionne super bien en merge), et de pouvoir travailler en petite équipe en marge d'un repo officiel, pour présenter par exemple un gros refactoring, ce qui au final est souvent nécessaire sur les projet, puisqu'en ce complexifiant, il faut ranger les fichiers autrement, etc.
Pour l'hébergement, on trouve pas mal de site de repo Mercurial, personnellement j'ai fini par utiliser http://assembla.com (c'est une forge, mais pas forcément centrée que sur le développement pure et dure, c'est plutôt bien), même s'il lui manque de pouvoir disposer de plusieurs repo pour le même projet (notamment pour gérer des branches sous forme de repo plutôt qu'en interne à un repo, ce que j'aime moins). Pour Git il y a surtout le fameux GitHub, très utilisé, et pour Bazaar je ne connais pas d'autre hébergement que Launchpad.
[^] # Re: SVN c'est has been :)
Posté par ploum (site web personnel, Mastodon) . Évalué à 4.
Quelques petites questions :
- Qu'entends-tu par "refactoring" des répertoires ? Peux-tu me donner un exemple ou svn merde et bzr marche bien ?
- "la gestion des branches de SVN, et particulièrement les rennommages / déplacements / compléments de fichiers déplacé est minable"
Idem, tu pourrais me donner un exemple pour que je comprenne bien ?
Désolé hein, mais j'avoue que je ne suis pas super bien tout ton raisonnement, je suis pas très bon en VCS.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: SVN c'est has been :)
Posté par Temsa (site web personnel) . Évalué à 4.
- Le refactoring de répertoire doit pouvoir fonctionner a peu pres correctement (avec un svn move ou un truc du genre, du coup pour ce problème, ça vient d'un défaut de svn dont je vais reparler, mais pas forcément de la ligne de commande, plutôt des interfaces qui se greffent dessus), néanmoins essais dans Eclipse, Nautilus ou un Explorateur windows d'aller dans un répertoire contenant lui même plein de sous répertoires qui sont eux meme committé. Tu fais un couper-coller pour le mettre dans un autre répertoire quelconque lui même déjà sous SVN.
Là, c'est le drame : tu te payes pleins d'erreurs pas possibles, voire parfois si tu commit un fichier dans un sous repertoire de cette arboresence, j'ai l'impression que tu commit tout ça à l'acncien endroit.
Pourquoi ? c'est simple. A l'instar de cvs, svn, créé un répertoire .svn dans chaque répertoire contenant les informations sur le répertoire courant, et l'endroit où il se trouve dans l'arborescence du projet, avec notre copier-coller, on a gardé ce répertoire, qui contient désormais les anciennes informations de où se trouve nos répertoire, pas de bol c'est faux.
Du coup si vous voulez committer l'arbo à la nouvelle place, il ne vous reste plus qu'a vous supprimer tous les ".svn" de tous les sous répertoires. Enfin bon, la fois d'après vous aurez été plus malin, et vous ferez directement un svn export ou un svn move, mais l'action naturelle ne fonctionne pas, et tous les nouveaux de ma boite se font piéger systématiquement.
En comparaison, les hg, git ou bzr ont bien un equivalent du ".svn", sauf qu'il n'y en a qu'à la racine du checkout(donc un copier-coller n'embarque pas des information invalides), et ils retrouvent leur bébé même après avoir déplacé un fichier, en retrouvant tout seul son historique (je suppose que ca se base sur un hash des fichiers pour les retrouver, mais j'ai pas verifié). Bref, ils font juste ce qu'ils doivent faire.
- 2e point, les merge avec des refactoring: Là je citerai le redbook SVN ( http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.branchm(...) ) :
A common desire is to refactor source code, especially in Java-based software projects. Files and directories are shuffled around and renamed, often causing great disruption to everyone working on the project. Sounds like a perfect case to use a branch, doesn't it? Just create a branch, shuffle things around, then merge the branch back to the trunk, right?
Alas, this scenario doesn't work so well right now, and is considered one of Subversion's current weak spots. The problem is that Subversion's update command isn't as robust as it should be, particularly when dealing with copy and move operations.
When you use svn copy to duplicate a file, the repository remembers where the new file came from, but it fails to transmit that information to the client which is running svn update or svn merge. Instead of telling the client, “Copy that file you already have to this new location”, it instead sends down an entirely new file. This can lead to problems, especially because the same thing happens with renamed files. A lesser-known fact about Subversion is that it lacks “true renames”—the svn move command is nothing more than an aggregation of svn copy and svn delete.
Dans les faits : créé une branche pour pouvoir réorganiser tes fichiers, déplace les (même avec un svn move et pas un copier-coller, ça change rien sauf le problème des .svn) puis commit dans ta branche, renommes en certains, puis commit dans ta branche, après corrige les chemins qu'il y a dans les fichiers (ça peut être les noms de package en java, ou le chemin relatif vers un répertoire), puis commit.dans ta branche.
Vu que tu a créé une branche, c'est parce que faire ce boulot et corriger tous les fichiers devait te prendre au moins 2-3 jours pendant lesquels tu ne pouvais bloquer les développements de tes collègues, donc qu'on fai tes collègues pendant ce temps ? Ils ont bossé sur les même fichiers que toi dans l'ancienne arborescence. Là on se dit, c'est pas grave, SVN va comprendre que j'ai déplacé, renommé les fichiers en question et me proposera de merger mes changements avec ceux de mes collègues.
Alors là tu te mets à regarder comment faire ton merge, et déjà, t'y comprends rien parce qu'il faut utiliser la version n-1 de ton développement pour le merge, et mettre des référence sur quel est l'origine de la branche et quel et la version avec laquelle on veut merger.
Et là, tu tombes dans ce cas :
For example, suppose that while working on your private branch, you rename integer.c to whole.c. Effectively you've created a new file in your branch that is a copy of the original file, and deleted the original file. Meanwhile, back on trunk, Sally has committed some improvements to integer.c. Now you decide to merge your branch to the trunk:
$ cd calc/trunk
$ svn merge -r 341:405 http://svn.example.com/repos/calc/branches/my-calc-branch
D integer.c
A whole.c
This doesn't look so bad at first glance, but it's also probably not what you or Sally expected. The merge operation has deleted the latest version of integer.c file (the one containing Sally's latest changes), and blindly added your new whole.c file—which is a duplicate of the older version of integer.c. The net effect is that merging your “rename” to the branch has removed Sally's recent changes from the latest revision!
This isn't true data-loss; Sally's changes are still in the repository's history, but it may not be immediately obvious that this has happened. The moral of this story is that until Subversion improves, be very careful about merging copies and renames from one branch to another.
Bref, dans certains cas, le merge gueule pas (enfin ça, c'est rare) et il vire juste les changements que tes collègues ont fait... Mais bon c'est pas tout :
To complete our running example, we'll move forward in time. Suppose several days have passed, and many changes have happened on both the trunk and your private branch. Suppose that you've finished working on your private branch; the feature or bug fix is finally complete, and now you want to merge all of your branch changes back into the trunk for others to enjoy.
So how do we use svn merge in this scenario? Remember that this command compares two trees, and applies the differences to a working copy. So to receive the changes, you need to have a working copy of the trunk. We'll assume that either you still have your original one lying around (fully updated), or that you recently checked out a fresh working copy of /calc/trunk.
But which two trees should be compared? At first glance, the answer may seem obvious: just compare the latest trunk tree with your latest branch tree. But beware—this assumption is wrong, and has burned many a new user! Since svn merge operates like svn diff, comparing the latest trunk and branch trees will not merely describe the set of changes you made to your branch. Such a comparison shows too many changes: it would not only show the addition of your branch changes, but also the removal of trunk changes that never happened on your branch.
Bon, par manque de temps(je dois partir au boulot), je vais te laisser lire la suite du redbook pour voir tous les problème qu'on se prend dans la gueule avec SVN. Mais pour résumer, c'est pas naturel, pas pratique, ça marche mal, et grossomodo il faut te faire les merges de fichier déplacé, renommés et retravaillé de chaque côté entièrement à la main, merci SVN...
Pendant ce temps là, tu prend un DVCS (bzr, hg ou git, mais me parlez pas de svk). Eux, par nature, comme on doit toujours pouvoir merger 2 repositories facilement sont obligé de gérer correctement ces merge avec déplacement / renommage /modification de fichier. en bref, ça se fait tout seul, et si jamais il y a un conflit entre le 2 code, seul les lignes impactée sont présentées par l'interface de merge, même si les fichiers n'ont rien à voir et ne sont plus du tout au même endroit. Le DVCS fait son job et retrouve l'historique des modifications pour permettre de faire le merge, bref, exactement ce qu'on lui demande.
Merger une branche avec le tronc (représentant 3-4 jours de travaille elle même) dans svn sur un projet conséuqent bloque les developpement de tout le monde pendant 1/2 journée pour le merge voire 1 journée, de plus vous aurez probablement quelques régressions fonctionnelles sur le code developpé sur le tronc, et il vous faudra tout revérifier derrière. Je suis désolé mais je trouve ça minable, surtout quand un hg, bzr ou git règle ca en 5 minute pour le même travaille. C'est tellement vrai que je connais des gens qui font les merge de branche sur svn via git parce que ça leur fait gagner beaucoup de temps.
Il parait que svn 1.5 doit arranger pleins de choses, néanmoins pour moi il est tellement à côté de la plaque au niveau de mes besoins quotidiens que je n'ai même pas envie de lire la doc de la super interface pas logique qu'ils ont du nous pondre pour gérer ça (le coup de la version n-1 à noter sur un papier pour un merge ... Ca mérite un coup de boule pour celui qui a pensé à un truc aussi pas logique par rapport a l'utilisateur, je pense qu'à la prochaine version il devrait prendre prendre 1+sqrt(5)/2 fois le numerio de version arrondi au dessus, ce serait moins pratique encore).
[^] # Re: SVN c'est has been :)
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Pendant ce temps là, tu prend un DVCS (bzr, hg ou git, mais me parlez pas de svk).Qu'est-ce que tu reproches à SVK ? C'est bien un DVCS. Déconnecté plus que Decentralisé, certes.
[^] # Re: SVN c'est has been :)
Posté par Antoine . Évalué à 1.
Déconnecté de la réalité ? :)
SVK est buggé, anti-intuitif, sous-documenté, et beaucoup moins puissant que les DVCS actuels. Autant l'éviter.
[^] # Re: SVN c'est has been :)Ba
Posté par Temsa (site web personnel) . Évalué à 2.
[^] # Re: SVN c'est has been :)
Posté par Bozo_le_clown . Évalué à 1.
Or la 1.5 qui est maintenant officielle, pallie bon nombre voire tous ces défauts.
C'est une version majeure qui apporte notamment la mémoire de merge (dont découle les problèmes que tu évoques) ainsi que le cherrypicking entres autres améliorations.
Traiter le cas d'utilisation que tu décris devient maintenant aussi simple et efficace que ca
http://blog.red-bean.com/sussman/?p=92
Il serait donc vraiment bon que tu te réfères à la dernière version du red-bean book pour la 1.5 avant de formuler tes critiques ou mieux que te retestes et que tu nous fasse part de tes impressions.
http://svnbook.red-bean.com/nightly/en/index.html
[^] # Re: SVN c'est has been :)
Posté par P.-A. . Évalué à 3.
Le problème le plus important que Temsa aborde (de mon point de vue en tous cas), c'est essentiellement le refactoring dans les branches (donc du svn move après un svn copy) et là, d'après la nightly doc, rien n'a changé. Il ne me semble pas non plus avoir vu qqch à ce sujet sur les articles du blog de subversion.
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advan(...)
[^] # Re: SVN c'est has been :)
Posté par Bozo_le_clown . Évalué à 1.
Ici on trouve un cas qui se rapproche
http://markphip.blogspot.com/2006/12/subversion-moverename-f(...)
et il semble que ce pb soit maintenant résolu.
http://markphip.blogspot.com/2006/12/subversion-15-improveme(...)
Je ferai mes propres tests lorsqu j'aurai un moment.
[^] # Re: SVN c'est has been :)
Posté par P.-A. . Évalué à 2.
Par contre il parle clairement du problème de design de l'implémentation du move dans SVN (finalement un svn delete + svn add) et que le problème est complexe : http://subversion.tigris.org/issues/show_bug.cgi?id=898
Sur ce bug on peut également trouver un PPT d'un mec qui fait un état des lieux des problèmes actuels à ce sujet : http://subversion.tigris.org/nonav/issues/showattachment.cgi(...)
[^] # Re: SVN c'est has been :)
Posté par Bozo_le_clown . Évalué à 2.
J'ai l'impression qu'on n'est pas encore prêt à se débarrasser de Clearcase dans ma boite.
Existe t'il des DVCS qui soient bien intégrés avec Eclipse et Windows ?
[^] # Re: SVN c'est has been :)
Posté par Temsa (site web personnel) . Évalué à 5.
Marche très bien sur tous les OS, a de bonnes intégrations, est très rapide, fait juste ce qu'on veut. Terrible quoi :)
[^] # Re: SVN c'est has been :)
Posté par Temsa (site web personnel) . Évalué à 2.
Mais je suis loin d'être sur que tout soit réglé, le gros problème comme c'est bel et bien la gestion du move qui est un add + delete.
cf. d'ailleurs les gens qui ont fouillés un peu plus svn 1.5 que moi.
[^] # Re: SVN c'est has been :)
Posté par P.-A. . Évalué à 2.
[^] # Re: SVN c'est has been :)
Posté par Amand Tihon (site web personnel) . Évalué à 4.
Et d'après les réponses obtenues sur la mailing-list, il ne faut pas espérer une solution rapidement, parce qu'il y aurait un problème de fond. Super...
# et Le café?
Posté par eMerzh (site web personnel) . Évalué à 2.
Un des avantage est qu'il s'intégre assez bien avec d'autre SCM comme svn justement, pas besoins donc de migrer toute l'archi d'un coup.
Ensuite, Bzr supporte assez bien plusieurs manière de travailler (http://bazaar-vcs.org/Workflows ) et ne nécessite pas forcément un serveur comme pour svn (un serveur http, ssh ou autre peut faire l'affaire... c'est trèèèès pratique).
# et SVK
Posté par Yves Agostini (site web personnel) . Évalué à 1.
J'étais en train de lire ça
http://developer.mozilla.org/en/Using_SVK_With_Mozilla_CVS
pour utiliser un gestionnaire décentralisé sur un vieux cvs
[^] # Re: et SVK
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
[^] # Re: et SVK
Posté par Temsa (site web personnel) . Évalué à 1.
http://weblogs.mozillazine.org/preed/2007/04/version_control(...)
[^] # Re: et SVK
Posté par Bozo_le_clown . Évalué à 0.
En voici 2 autres qui tendrait à montrer le contraire
http://www.collab.net/community/subversion/articles/Subversi(...)
[^] # Re: et SVK
Posté par Temsa (site web personnel) . Évalué à 2.
[^] # Re: et SVK
Posté par Temsa (site web personnel) . Évalué à 2.
# Des réponses
Posté par Adrien . Évalué à 3.
L'avantage est que tu peux commiter, même si ton serveur n'est pas dispo. Typiquement j'ai envie de modifier mon CV dans le train (ou quand je n'ai pas internet), je peux faire mes modif, commiter tout ce que je veux, et quand mon serveur est dispo hop je sauvegarde.
Perso j'utilise Mercurial, qui est *beaucoup* plus simple à prendre en main que git.
Un petite comparaison pour la blague entre git et mercurial, assez imagée : http://importantshock.wordpress.com/2008/08/07/git-vs-mercur(...)
[^] # Re: Des réponses
Posté par Temsa (site web personnel) . Évalué à 4.
- Des merges faciles et bien foutus
- Des refactoring qui posent pas de problème et qui ne nécéssitent souvent même pas une branche.
- La possibilité de maintenir un patch aisément par rapport, par exemple, à un produit open source (exemple typique: cablage du sso interne sur un forum php libre, ou maintenance d'un patch en attendant qu'un mainteneur l'intègre) ou un produit d'entreprise (ex: gérer le spécifique d'un client dans un repo dans lequel on importe les modifs du produit de base au fur et à mesure).
- Facilite le libre car tout un chacun peut se faire son propre repo, son propre hack à partir d'un projet libre, et le présenter facilement au mainteneur une fois que celui-ci fonctionne bien. Ca facilite grandement la méritocratie, et ne demande pas à quelqu'un de travailler dans de mauvaises conditions ou de devoir lui faire confiance sans savoir si on peut en lui filant des accès dev qu'il n'a pas prouvé mériter.
- La plupart sont plus rapides que les VCS habituels
- La plupart gèrent correctement les fichiers binaires
# outils
Posté par CrEv (site web personnel) . Évalué à 1.
Heu... il existe un plugin pour thunar et surtout kdesvn !
Il est vraiment pas mal foutu et s'intègre assez bien (après oui je suis d'accord, c'est du kde, c'est super pratique dans un onglet de konqueror par ex, etc...)
Mais en tout cas c'est mon client svn par défaut (et l'autre est la ligne de commande)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.