> On peut également reprocher certaines choses à svn (comme l'impossibilité d'annuler un commit)
On peut annuler un commit. Mais il faut savoir ce que tu entends par annuler. Ce qu'on peut faire avec svn, c'est ajouter une transaction qui annule la précédente. La précédente est toujours dans le dépôt mais n'est plus visible dans la version HEAD. Pour ce faire on "commit" l'inverse du commit qu'on veut annuler (ça demande qu'une ligne de commande).
Notons qu'il n'y a guêre le choix.
Tu soumets des modifications et avant que tu "annules" d'autres peuvent avoir fait un "svn update". Il y a le même problème avec git...
Tu peux "réellement" annuler une transaction si t'es admin. C'est possible, mais ce n'est pas recommandé.
> Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.
Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.
> De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.
Tu peux aussi le faire avec svn.
> Maintenant, le même scénario avec Git se serait beaucoup mieux passé.
Je ne vois pas pourquoi. Si des fichiers sont en conflit, ben ils sont en conflit. Avec svn ou git, ils sont en conflit.
De plus tu n'es pas obligé de bosser sur la branche truck. Tu peux avoir une branche de développement que tu synchronises de temps à autres avec trunk (tu merges ce qui est fait dans trunk). C'est très commun comme usage de svn. Lorsque tu es content de ta version tu envois le diff entre ta blanche de développement et trunk. Ta branche de développement peut être un dépôt subversion local ou être sur le serveur principal.
Mes dépôts subversions n'ont pas de développement direct dans /trunk. Tout est fait dans /devel. Lorsqu'une modification est satisfaisante, elle est fusionnée dans trunk. C'est un modèle qui a ses avantages et inconvénients. Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).
> Enfin, je n'aurais rencontré aucune difficulté à annuler un des mes changements.
Il n'y a aucune difficulté à annuler des changements avec svn.
> Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages
On peut le faire sans bidouillage.
> Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.
Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).
> Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.
Non, l'intérêt n'est pas là.
Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.
# Re:
Posté par IsNotGood . En réponse au journal Pourquoi Git m'importe ?. Évalué à 10.
On peut annuler un commit. Mais il faut savoir ce que tu entends par annuler. Ce qu'on peut faire avec svn, c'est ajouter une transaction qui annule la précédente. La précédente est toujours dans le dépôt mais n'est plus visible dans la version HEAD. Pour ce faire on "commit" l'inverse du commit qu'on veut annuler (ça demande qu'une ligne de commande).
Notons qu'il n'y a guêre le choix.
Tu soumets des modifications et avant que tu "annules" d'autres peuvent avoir fait un "svn update". Il y a le même problème avec git...
Tu peux "réellement" annuler une transaction si t'es admin. C'est possible, mais ce n'est pas recommandé.
> Avec subversion, seules les personnes autorisées peuvent accéder au dépôt et créer des branches pour faire des essais.
Cette politique est à la discrétion de l'admin. Des admins autorisent tout le monde à écrire dans la branche /devel par exemple. D'autres mettent tout en rw pour tout le monde car on peut "annuler" toute modification.
> De l'autre coté, n'importe qui peut cloner un dépôt Git, créer sa branche expérimentale et continuer à suivre les développements fait sur le dépôt officiel.
Tu peux aussi le faire avec svn.
> Maintenant, le même scénario avec Git se serait beaucoup mieux passé.
Je ne vois pas pourquoi. Si des fichiers sont en conflit, ben ils sont en conflit. Avec svn ou git, ils sont en conflit.
De plus tu n'es pas obligé de bosser sur la branche truck. Tu peux avoir une branche de développement que tu synchronises de temps à autres avec trunk (tu merges ce qui est fait dans trunk). C'est très commun comme usage de svn. Lorsque tu es content de ta version tu envois le diff entre ta blanche de développement et trunk. Ta branche de développement peut être un dépôt subversion local ou être sur le serveur principal.
Mes dépôts subversions n'ont pas de développement direct dans /trunk. Tout est fait dans /devel. Lorsqu'une modification est satisfaisante, elle est fusionnée dans trunk. C'est un modèle qui a ses avantages et inconvénients. Il est présenté/discuté dans la doc de subversion (que tu devrais lire avant de parler de subversion).
> Enfin, je n'aurais rencontré aucune difficulté à annuler un des mes changements.
Il n'y a aucune difficulté à annuler des changements avec svn.
> Ici, on peut assez facilement s'en sortir avec svn et quelques bidouillages
On peut le faire sans bidouillage.
> Pour moi, la grande force des gestionnaires de versions distribués est là : pouvoir créer une branche même sans accès au dépôt officiel.
Pareil avec svn... Tu peux faire ton dépôt local si tu veux. Puis tu synchronises à la main (comme tu le fais avec git...).
> Les gestionnaires de versions distribués cassent cette barrière entre ceux qui ont accès au dépot officiel et les autres.
Non, l'intérêt n'est pas là.
Franchement, si tu n'aimes pas svn et préfère git, ben utilises git. Mais ne dis pas que tel ou tel truc avec svn n'est pas possible sans te renseigner.