Cette transition délicate est maintenant terminée (depuis le 5 mai) et le travail a repris de plus belle sur les serveurs KDE pour pouvoir nous proposer un bureau encore plus performant et complet. Quelle est la raison de ce basculement vers Subversion ?
Selon le message de Tobias Koenig datant du 10 octobre cette transition est nécessaire pour préparer l'arrivée du futur KDE 4 ce qui va entraîner beaucoup de ménage ("move" et "rename" de branches) qu'il est très difficile d'effectuer avec CVS.
De plus les améliorations de SVN apportent un bénéfice supplémentaire non négligeable par rapport à CVS (le message évoque les "dépôts cachés" sur des disques locaux pour éviter des connexions incessantes au serveur principal) et, cerise sur le gâteau, les commandes sont presque identiques entre les deux logiciels
Ce basculement de KDE vers Subversion est le plus grand jamais effectué et le script de conversion a tourné pendant 38 heures avant d'en finir ! L'archive KDE maintenant présente dans le dépôt Subversion représente 15 Go de données.
Enfin on peut noter que du coté du bureau Gnome c'est CVS qui reste la norme mais une discussion commence à apparaître pour effectuer également le basculement et une session sera consacrée à ce sujet lors des rencontres Gnome de Stuttgart à la fin de ce mois.
Aller plus loin
- L'annonce sur KDE.org (1 clic)
- Le manuel Subversion pour KDE (1 clic)
- Le Howto KDE-Subversion (1 clic)
- Le message de Tobias Koenig (1 clic)
- Utilisation de Subversion en français (2 clics)
- Et du coté de Gnome ? (2 clics)
# Subversion vs GIT
Posté par michael_acreall . Évalué à 1.
Puisque subversion dispose d'une architecture en couche,
n'aurait il pas été possible de remplacer l'attaque de la base de donnée berkley par l'attaque du file système ?
[^] # Re: Subversion vs GIT
Posté par dudule42 . Évalué à 10.
voir http://subversion.tigris.org/subversion-linus.html(...)
[^] # Re: Subversion vs GIT
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
En gros, Linus passe son temps à faire des merges d'arbre plutot que des patchs.
"La première sécurité est la liberté"
[^] # Re: Subversion vs GIT
Posté par reno . Évalué à 7.
Par contre, là ou je suis surpris c'est que le merge de fichier n'a pas l'air d'être le problème numéro 1 de Linus..
Pourtant pour avoir joué au "mergeur" sur du CVS, c'est ch...^W pénible, et apparemment BK était assez bon sur ce sujet.
Ceci dit, je ne vois pas comment BK pouvait être meilleur que le classique 3-way merge, mais je doit manquer d'imagination!
PS: Je me demande si Mercurial a une chance contre git?
[^] # Re: Subversion vs GIT
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
Je ne connais pas trop BK (jamais utilisé), mais le merge de base est une forme de 3-way merge.
En fait, une des grosses difficultés, c'est plus la recherche de l'ancetre commun que le merge lui-même (qui est un problème relativement bien résolu aujourd'hui, même si il y a encore des cas ou on pourrait faire mieux). Pour ça, il faut garder un historique de qui a mergé qui, qui est une branche de qui, ... ce que CVS par exemple ne fait pas. Il faut aussi un système de nommage qui permette de garantir l'unicité du nom sans pour autant qu'il n'y ai d'autorité centralisée d'attribution des noms (l'information "j'ai mergé avec toto version 42" n'est intéressante que si il y n'y a qu'un seul "toto" au monde ...). D'ou les histoires de SHA1 pour git et les adresses email dans les noms d'archives GNU Arch.
[^] # Re: Subversion vs GIT
Posté par golum . Évalué à 5.
http://linuxfr.org/~mammique/17910.html(...)
extrait du svnbook
http://svnbook.red-bean.com/en/1.1/svn-book.html#svn-ch-4-sect-3.3.(...)
[^] # Re: Subversion vs GIT
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
C'est ce qu'il me semblait en fait. C'est d'ailleurs un des ajouts de svk par rapport a subversion. (GNU arch garde aussi l'historique des merge)
# Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) ...
Posté par Victor STINNER (site web personnel) . Évalué à 10.
— On peut charger uniquement une partie du dépôt et bosser dessus (dans CVS, ça se passe par "module")
— On n'a pas besoin de se connecter au serveur pour faire un ajout ou une suppression (chose que je n'ai jamais comprise dans CVS) : ceci rend la préparation d'un commit beaucoup plus agréable
— Un diff par rapport à la dernière version commitée se fait sans se connecter au serveur (chose magnifique), de même pour avoir avec "status" de répertoire local (ça fait tout bizzare au début de ne pas avoir à attendre 5 min ;-)). De plus "status" est très bien présenté (affiche juste les fichiers qui ne sont pas dans le dépot, les fichiers ajoutés / supprimés, et les fichiers modifiés) : juste comme il faut
— Un commit SVN est moins bavard qu'un CVS qui remplit l'écran de plein de griboulli
— On peut créer un répertoire avec SVN (remplace un mkdir X; cvs add X; => lourd à cause de la connexion au serveur pour rappel)
— Il existe une fonction "magique" (quand on vient du monde CVS) : svn revert qui permet de revenir à la dernière version commitée
— Un update ajoute automatiquement les nouveaux fichiers (pas besoin d'ajouter -A à la commande)
— Le répertoire utilisés par SVN sont nommés ".svn", et sont donc cachés. Ceci est plus sympa que les répertoires CVS trop visibles à mon goût.
— La création de branche est plus pratique, il suffit de dupliquer un répertoire autre part, et hop, on a une branche ...
— Les numéros de versions (de commit) sont simplement incrémentés (1, 2, ...). C'est plus simple que des 1.1.1, 1.2.34, 1.54, ... (bon ok, c'est discutable, et je crois bien que CVS est plus souple à ce niveau là)
— Avec l'interface web (CvsWeb, qui comme son nom ne l'indique pas, sait aussi afficher du SubVersion) on peut voir l'ensemble des modifications d'un commit. Chose que je n'ai jamais réussi à faire avec CVS (peut-être avec un cvs history <options magiques> ?).
— Et puis il y a sûrement plein d'autres avantages. Pour rappel, SVN a été écrit car CVS a été mal pensé niveau sécurité (voir des sites de sécurité et compter le nombre de failles ...) et pour corriger les défauts de conception de CVS.
En fait, SVN duplique chaque fichier lors du premier "checkout", c'est pourquoi diff/status est si rapide (et revert possible).
J'ai jamais passé de dépôt CVS en SubVersion, mais il parait que ça se fait bien. Pour info, http://developer.berlios.de/(...) permet d'avoir un dépôt CVS et/ou SubVersion. C'est un des seuls à ma connaissance.
Pour voir à quoi ressemble à CvsWeb de SVN (y'a un p'tit bug UTF-8 par contre, peut-être parce que je suis en UTF-8 et pas le serveur) :
http://svn.berlios.de/viewcvs/happyboom/trunk/(...)
Pour info, HappyBoom est mon projet de réécriture de Wormux en Python et SDL, qui est aujourd'hui un projet expérimental de moteur réseau avec un système multi-agents.
@+ Haypo étonné de tartiner tellement sur cet outil ;-)
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par TImaniac (site web personnel) . Évalué à 10.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Pooly (site web personnel) . Évalué à 1.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par wilk . Évalué à 3.
Par exemple, si toto fait une modif sur le fichier X, titi renome X en Y, toto commit sa modif de X, que ce passe-t'il ?
Et est-il possible par la suite de savoir que Y s'apellait X dans les versions précédentes ?
par ex (avec bazaar-ng)
$bzr init
$echo "je suis X" > x
$bzr add x
$bzr commit -m "add x"
$bzr rename x y
$bzr commit -m "rename x y"
$echo "je suis Y" > y
$bzr commit -m "modif y"
$bzr diff -r 1 y
*** renamed file 'x' => 'y'
--- x
+++ y
@@ -1,1 +1,1 @@
-je suis X
+je suis Y
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Samson Thoias . Évalué à 2.
L'historique est gardé, avec une trace de l'ancien nom, de manière transparente.
Exemple concret:
svn log -v client.pl
[le log de la version 51 a 55]
A /othello/gui/client.pl (from /othello/gui/main.pl:51)
[log de la version 1 a 51]
Le fichier client.pl s'appellait main.pl, et a été renommé (avec svn mv)
à la revision 51.
L'option -v de log permet de voir ce genre de changement (et d'autres choses)
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par j . Évalué à 3.
Et puis oui, Subversion résoud toutes les absurdités de CVS, que ce soit pour renommer un répertoire, pour ajouter des liens symboliques, pour le "svn revert", pour le coup d'avoir la version précédente en local, etc. Et puis on critique SVN à cause de ses dépendances lorsque l'on souhaite utiliser Webdav. Mais mine de rien c'est super pratique. Au moins le HTTP avec ou sans SSL, ça passe partout, même derrière des firewalls trop paranos. Et le coup de pouvoir monter un répertoire Webdav quand on n'a pas encore le client SVN installé, c'est top.
Malgré l'arrivée d'OpenCVS, je n'ai vraiment pas envie de revenir à CVS, il a trop de limitations pénibles.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Christophe Fergeau . Évalué à 3.
Aux dernières nouvelles c'était pas encore ça pour tout ce qui concerne la fusion de branches (ie c'était aussi mauvais que CVS).
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Sébastien Dinot (site web personnel) . Évalué à 1.
La première impression est très positive mais :
* Bien qu'annoncé comme le fils spirituel de CVS, Subversion requiert un certain temps d'adaptation car certains aspects sont traités de manière très novatrice pour un adepte de CVS.
* Subversion peut stocker les fichiers dans une base Berkeley DB ou dans son propre « système de fichiers », FSFS. L'expérience m'a montré que les droits d'accès sont problématiques avec une base Berkeley DB dans un contexte multi-utilisateur. D'ailleurs, dans le livre « Version Control with Subversion », il est conseillé d'utiliser dans ce cas un espace de stockage de type FSFS.
* Les répertoires administratifs .svn contiennent deux copies de chaque fichier importé dans le référentiel. Cela permet d'effectuer des diffs et d'autres opérations en local et présente de sérieux avantages. En contrepartie, la copie de travail du projet s'avère donc 3 fois plus volumineuse que les sources originelles. Quelqu'un a dit que le projet KDE représentait 15 Go de sources. Pour importer une copie de travail intégrale du projet, il faut donc prévoir 45 Go d'espace disque !
Mais une fois ces problèmes assimilés, il est vrai que Subversion a de nombreux atouts pour séduire, à commencer, pour moi, par les commits atomiques, la gestion des répertoires, le renommage et le déplacement de fichiers sans perte de l'historique.
Sébastien
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Romain Vinot . Évalué à 4.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Jean-François Wauthy . Évalué à 3.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Pierrick Le Gall (site web personnel) . Évalué à 6.
Oui, et à mon avis tu as oublié le plus important de tous : l'atomicité des commits. Pour moi, c'est ça la "killer-feature" de Subversion par rapport à CVS.
Sous CVS, les commits sont gérés fichier par fichier. Les numéros de version sont indépendants fichier par fichier. Et lorsqu'on fait des merges entre branches sur un module complet, faut s'accrocher. Par exemple il faut bien du courage pour faire un merge entre une branche A et une branche B à partir d'autre chose que les dernières versions des fichiers sur la branche mergée. (tout simplement parce qu'on ne peut pas faire à la fois -r <ma_branche> et -D <ma date>) La solution que j'emploie est un peu batarde, limite lourdingue : mettre des tags sur l'intégralité des mes modules sur les niveaux des commits que je suis susceptible de vouloir merger plus tard :-/
Sous SVN, tranquille, j'ai un numéro de version à merger, je le connais, il est unique : les numéros de version, en plus d'être simplifiés car sous forme d'entier incrémenté, sont propre au dépôt complet.
[^] # Re: Pour ceux qui hésitent encore à franchir le pas (CVS à SubVersion) .
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Haypo
# KDE 4
Posté par marseillais (site web personnel) . Évalué à 4.
Je ne suis pas sous linux deppuis assez longtemp pour connaitre les rythmes de sorties des versions de KDE ni meme si les avancés entre un KDE 3 et un KDE 4 sont enormes. Donc en gros je me demande :
- a quand le prochain KDE? 3.5 ou 4? les sorties sont a dates fixes? ou simplement quand les developpeurs considérent qu'une sortie serait de bon tons?
- a quels nouveautés peut on s'attendre dans KDE 4? j'ai lu ceci : http://aseigo.bddf.ca/?pID=1221(...) j'en ai appris pas mal malgré mon anglais. Mais ca ne dit pas vraiment grand chose sur le "eye candy".
en gros a quoi peut on s'attendre pour KDE4? et a t'on unee idée de quand il devrait sortir?
[^] # Re: KDE 4
Posté par dguihal . Évalué à 3.
Je pense que l'on verra un KDE 3.5 contenant un lot de bug fix avant
[^] # Re: KDE 4
Posté par Sebastien . Évalué à 5.
Mais les dates ne sont pas encore fixées, même si c'est sur qu'il va falloir attendre que Qt4 se stabilise pour pouvoir sereinement baser une release de KDE dessus.
Cependant, le développement pour KDE4 a débuté : wouhou ! (Cf blog d'Aaron Seigon).
En effet, kdelibs a été compilé avec Qt4 : c'est le commencement du début.
Par contre je n'ai trouvé aucun tag ni aucune branche KDE4-dev ou quoi que ce soit d'approchant sur le SVN de KDE...
[^] # Re: KDE 4
Posté par Mickael Marchand . Évalué à 10.
le boulot a commence mais non, kdelibs ne compile pas entierement ;)
DCOP a ete porte et devrait meme etre compat avec le DCOP de kde3.x.
Reste a faire des tests reels pour voir ce que ca donne.
kdecore, on a presque fini, encore quelques portages a faire. Peut-etre ce soir, si j'ai le temps j'essaierai de tout finir (y a des subtilites a travailler tout de meme, et je ne parle que de "faire compiler" la bete ...) (de la a ce qu'on puisse lancer une KApplication, y aura sans doute encore un pas ;)
kdeui, alors la c'est pas pour demain, plein de changements a faire ;)
kio, devrait a priori pas etre trop complique d'apres ce que j'ai pu en voir...
le reste de kdelibs devrait suivre sans trop de problemes normalement
Maksim a deja porte kdefx ainsi qu'un style de base pour les fenetres, il va attaquer keramik il me semble.
Thiago s'est occupe de la couche reseau qu'il avait prepare depuis un moment.
apres il faudra voir pour kdebase ou y aura un boulot enorme egalement.
une fois qu'on aura tout ca, qu'on aura bien compris toutes les subtilites, y a moyen que ca aille un peu plus vite pour le reste des applis.
bref, pour voir demarrer un kde4 (encore faudrait-il en avoir envie hein parce que pour le moment ... ;), il faudra compter plusieurs semaines ;)
Mik
[^] # Re: KDE 4
Posté par Amaury . Évalué à 4.
C'est pas plutôt ici http://websvn.kde.org/branches/work/kde4/(...) ?
[^] # Re: KDE 4
Posté par Mickael Marchand . Évalué à 2.
(vieille URL qui trainait dans mon konqui)
Mik
[^] # Re: KDE 4
Posté par cosmocat . Évalué à 6.
KDE 4 est dépendant de la sortie de QT4. Et du fait d'une sortie non fixée de QT4, la date de sortie de KDE 4 ne peut être fixée elle-même.
A l'origine, il me demble que KDE 3.4 n'était pas prévue car ils devaient passer directement à la version 4 mais QT 4 se fait attendre donc une version 3.5 vera surement le jour.
Pour KDE 4, les developpeur devront se familiariser avec les nouvelles API et le developpement de la branche 4 ne peut commencer car des changements fondamentaux en dépendent.
Pour les apports de KDE 4, on devrait s'attendre à une plus grande rapidité (car QT4 est annoncé plus rapide), l'abandont de arts et l'integration d'un des (je sais pas comment on dit) "gestionnaire de son". Il a pas été encore choisi (gstreamer,et d'autres ...)
Voilà, t'en sais autant que moi ;)
[^] # Re: KDE 4
Posté par marseillais (site web personnel) . Évalué à 3.
pour les nouvveautés de KDE4 j'ai vu qu'apparemment ils bossent actuellemennt sur un systéme d'indexation du disque dur permettant de faire des recherches rapide et plus pertinente a la WinFS apparemment.
Et pour le son ben jsuis bien content parce que j'ai souvent des problémes de son.
Sinon bah pour le moinssage je comprend pas trop! le hors sujet peut etre.
[^] # Re: KDE 4
Posté par patrick_g (site web personnel) . Évalué à 2.
http://linuxfr.org/2004/07/09/16762.html(...)
[^] # Re: KDE 4
Posté par Ludovic Gasc . Évalué à 2.
Certains développeurs KDE ont déjà commencé à porter des petits bouts de KDE sur QT4 avec la version en développement.
Pour le moteur de sons, il est normalement prévu de laisser le choix à l'utilisateur/distrib, y'aura une couche d'abstraction qui s'appellera kdemm.
[^] # Re: KDE 4
Posté par Romain Vinot . Évalué à 3.
Pour les librairies de base de KDE, les développeurs ont déjà commencé à intégrer QT4 (avec la dernière version beta) depuis quelques jours. Donc le boulot a commencé, mais ce sera pas fini avant... pfiou, longtemps.
En attendant, pour ne pas rester pendant plus d'un an sans release, ils ont prévu un KDE3.5 qui ne touchera pas aux libs de base mais qui permettra aux développeurs d'applications KDE de continuer à ajouter des features.
# De l'espoir...
Posté par Julien Damon (site web personnel) . Évalué à 3.
Personnellement, j'attends encore un outils proche de ce que fait TortoiseSVN sous Windows pour mes deux desktop préférés (KDE & Gnome)... Mais, j'ai appris à être patient !
(Ceci dit peut être ai-je raté un projet existant sur le sujet ?)
[^] # Re: De l'espoir...
Posté par Julien Duponchelle (site web personnel) . Évalué à 1.
[^] # Re: De l'espoir...
Posté par Infernal Quack (site web personnel) . Évalué à 2.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: De l'espoir...
Posté par Christophe Lafaille . Évalué à 3.
Egalement disponible, eSVN écrit en Qt ( http://www.kde-apps.org/content/show.php?content=15338(...) )
Et aussi JSVN, écrit en java ( http://jsvn.alternatecomputing.com(...) )
Je n'ai testé aucun de ces outils ni fait la moindre comparaison avec TortoiseSVN (http://tortoisesvn.tigris.org(...) ).
Peut-être que d'autres existent...
[^] # Re: De l'espoir...
Posté par Christophe Lafaille . Évalué à 1.
# Details de la migration
Posté par Sebastien . Évalué à 3.
Une migration de cette taille ne s'est sûrement pas passée sans heurts (1 mois de décalage entre la lettre d'intention (1 Avril) et la date effective) et j'aurais donc voulu avoir accès à cette expertise...
PS: mon ami google me donne juste des pointeurs vers comment se servir de SVN pour les commits de KDE...
# Quid de GNU Arch?
Posté par woam . Évalué à 1.
que pensez-vous du prometteur GNU Arch? Il est utilisé je crois pour le développement de la Ubuntu.
Extrait du manuel francisé http://flibuste.net/libre/tlafr/(...) :
Cette distribution des sources et des droits de modification me semble très prometteuse, notamment pour le monde du logiciel libre. Participer, collaborer, forker, ou réutiliser une ou plusieurs archives deviens pratique courante. La production coopérative confortable :) Est-ce simplement un manque de visibilité de GNU Arch dû à sa jeunesse qui vous fait préférer SubVersion? Ou bien voyez-vous dans cette distribution des archives une fausse bonne idée difficilement applicable actuellement?
Bref, je pense qu'un retour d'expérience ou un simple avis sur la question pourrait intéresser du monde :)
[^] # Re: Quid de GNU Arch?
Posté par patrick_g (site web personnel) . Évalué à 0.
je n'ai pas un avis d'expert mais d'après ce qu'on peut lire sur internet il semble que la syntaxe des commandes d'arch soit vraiment pourrie jusqu'au trognon.
le concept de gestionnaire de code distribué est bon et il existe beaucoup d'alternatives : je crois que Bazaar reprends le meilleur d'arch en essayant de corriger les erreurs....et maintenant y'a bazaar-NG (developpé par ubuntu) et qui doit être LE TRUC ULTIME en matière de gestionnaire décentralisé.
[^] # Re: Quid de GNU Arch?
Posté par Johann Deneux . Évalué à 3.
[^] # Re: Quid de GNU Arch?
Posté par or zax . Évalué à 5.
Arch à la qualité et le gros défaut d'utiliser des concepts que ne font pas partie des habitudes collectives.
Arch ne s'utilise pas du tout comme CVS, subversion à des similitudes, et un soucis pour faciliter la transition (on passe d'un système centralisé à un système décentralisé, ça n'aide pas)
Le gros des critiques sur Arch, plus que la syntaxe (moi je l'aime bien), c'est l'auteur Tom LORD que beaucoup critique au niveau de ses choix.
Arch est tellement différent qu'il fait peur. Moi j'ai commencé par Arch et ne connait pas le reste donc ce fut facile pour moi, je ne sais pas ce à quoi ressemble CVS ou subversion, mais arch je l'utilise professionnellement et avec beaucoup de plaisir.
Arch c'est la déroute, mais c'est cool !!
[^] # Re: Quid de GNU Arch?
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Disons que Tom a un certain nombre de gros défauts:
* Il aime bien commencer les choses, pas les terminer. Ceux qui suivent la mailing list de arch ont vu passer pas mal de projets (XL, support de git, réécriture complete pour la version 2, bugtracker ...), mais pas grand chose de concret.
* Il a un complexe de supériorité. « C'est comme ça que je fais, donc, c'est la bonne façon ». Ben non, c'est pas parce que lui, aime mettre des accolades dans les noms de fichiers que moi j'aime ça aussi ...
* Il aime réinventer la roue. Il a réinventé la manipulation des chaines de caractères, la gestion de la mémoire en C, les autotools, la programmation orientée objet, ... J'aurais préféré qu'il passe ce temps sur des choses utiles.
* Il ne supporte pas de déléguer. Réguliérement, quelqu'un tente de reprendre le développement de Arch (jblack, jivera), mais à chaque fois, le mec abandonne ou se fait virer au moment de la release candidate, et on jette son travail.
bazaar est un fork de tla fait par les gens de canonical, qui s'est affranchi un peu de tout ça. Y'a de l'espoir ...
--
Maybe I'm simply a more effective Unix user than many people. So, [...]
-- Tom lord, 18 Oct 2004.
[^] # Re: Quid de GNU Arch?
Posté par Yann Droneaud (site web personnel) . Évalué à 2.
(Mais je ne cherche pas à justifier le nommage des fichiers spécifiques à arch ;)
[^] # Re: Quid de GNU Arch?
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
thelove@canonical.com/bazaar-debian/bazaar-debian--debian/bazaar-debian--debian--1.4/bazaar-debian--debian--1.4--base-0/\{arch}/bazaar-debian/bazaar-debian--debian/bazaar-debian--debian--1.4/thelove@canonical.com/patch-log/base-0
sur ma machine (a l'intérieur d'un répertoire que j'ai choisi). Evidemment, sur un système de fichiers ou le chemin complet est limité a 256 caractères, on touche vite les limites.
[^] # Re: Quid de GNU Arch?
Posté par herodiade . Évalué à 3.
- soit dans l'interpreteur css de mozilla-firefox
- soit dans le code de linuxfr
Parceque le nom du fichier dépasse très largement du cadre chez moi.
[^] # Re: Quid de GNU Arch?
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
On pourrait eventuellement planquer ce qui dépasse en CSS. La, le choix de l'auteur de la CSS, si il a pensé a ce cas, c'est de laisser dépasser pour tout voir.
[^] # Re: Quid de GNU Arch?
Posté par Olivier Jeannet . Évalué à 2.
Evite STP de mettre des chaîne de caractères super longues, ça tue la mise en page, en particulier à l'impression (avec l'option "fit width" on se retrouve avec une police de taille genre 4, dur à lire).
Rajoute un espace (ou plus) pour permettre le "wrapping".
[^] # Re: Quid de GNU Arch?
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
OK,
---> [ ]
[^] # Re: Quid de GNU Arch?
Posté par wilk . Évalué à 1.
Le problème c'est que du fait qu'il est décentralisé il devrait être beaucoup plus simple à installer (pas de serveur par ex) et utiliser que subversion, hors c'est tout l'inverse, de fait il est inaccessible aux débutants, aux utilisateurs de windows etc... Et comme l'auteur est une sorte de génie qui nous déverse de très long discours théoriques (invention d'un nouveau langage, d'un wiki...) la plupart des contributeurs l'ont laissé tomber pour d'autres horizons plus accessibles.
Mais le principe reste extrèmement intéressant à mon goût et mérite d'être essayé.
Dès que possible je mettrai en parralelle le tutorial de gnuarch (un peu périmé) et celui de bazaar-ng, ça permettra de cerner rapidement les avantages et inconvénients de chacuns.
Comme tout ça est libre, il y a de plus en plus de passerelles pour aller de l'un à l'autre, aucun problème donc pour démarrer avec l'un et passer à l'autre au besoin.
[^] # Re: Quid de GNU Arch?
Posté par or zax . Évalué à 2.
[^] # Re: Quid de GNU Arch?
Posté par woam . Évalué à 4.
[^] # Re: Quid de GNU Arch?
Posté par or zax . Évalué à 2.
Même si je suis un pro Arch à fond, certaines fonctionnalités sous subversion n'existe pas sous Arch (et inversement), donc même si Arch peut centraliser les dépôts, il induit trop de changement dans les normes de développement.
Tu as essayé le dernier Arch 1.3.2, il est terrible, la série 1.3 remanie la cohérence des commandes, ça devient très sympas !
[^] # Re: Quid de GNU Arch?
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Disons qu'il y a quelques unes des nouveautés de bazaar que Tom s'est décidé a merger. Il reste encore beaucoup a bazaar (cache, archive registry, annotate, ...).
[^] # Re: Quid de GNU Arch?
Posté par or zax . Évalué à 3.
# Les grands esprits se rencontrent ?
Posté par oliv . Évalué à 5.
http://www.advogato.org/person/jamesh/diary.html?start=196(...)
Si j'en crois ce message, ils veulent faire "comme KDE" ;) (c'est juste un petit troll, j'ai pas pu résister)
http://mail.gnome.org/archives/gnome-hackers/2005-May/msg00001.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.