je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur certai ns
fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la lect ure de
200 pages de doc pour apprendre à se servir de chaque ordre possible (un
poil intuitif, ça changerait:)
je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur certai ns
fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la lect ure de
200 pages de doc pour apprendre à se servir de chaque ordre possible (un
poil intuitif, ça changerait:)
je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur certai ns
fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la lect ure de
200 pages de doc pour apprendre à se servir de chaque ordre possible (un
poil intuitif, ça changerait:)
Salut liste,
je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur
certains fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la
lecture de 200 pages de doc pour apprendre à se servir de chaque
ordre possible (un poil intuitif, ça changerait:)
Donc vos expériences sont le bienvenu.
JY
Salut liste,
je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur
certains fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la
lecture de 200 pages de doc pour apprendre à se servir de chaque
ordre possible (un poil intuitif, ça changerait:)
Donc vos expériences sont le bienvenu.
JY
Salut liste,
je ne connais ces systèmes que pour récupérer une version, mais
maintenant, pour un dev, j'ai besoin d'en utiliser un.
J'ai besoin de:
* Plusieurs branches (stable, unstable, dev),
* Pouvoir revenir (dès fois) de bcp de versions en arrière sur
certains fichiers seulement,
* Et surtout que ça ne soit pas une usine à gaz nécessitant la
lecture de 200 pages de doc pour apprendre à se servir de chaque
ordre possible (un poil intuitif, ça changerait:)
Donc vos expériences sont le bienvenu.
JY
serait il possible d'être un peut plus disert sur le sujet
concernant un équivalent de :
-a) "CVS"
-b) "SVN"
-c) "GIT"
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
serait il possible d'être un peut plus disert sur le sujet
concernant un équivalent de :
-a) "CVS"
-b) "SVN"
-c) "GIT"
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
serait il possible d'être un peut plus disert sur le sujet
concernant un équivalent de :
-a) "CVS"
-b) "SVN"
-c) "GIT"
est il possible de savoir si les clients sont win32 ou uniquement
GNU ...
Une question importante est de savoir qui va (au début, et surtout d ans
l'avenir) utiliser ce versionneur. Vas tu l'utiliser tout seul pour un
développement sur lequel tu es le seul à travailler?
Est-ce que les contributeurs futurs à ton développement logicie l seront
proches ou éloignés?
Développes tu sous et pour Linux?
S'agit-il d'une application web?
Est-ce un petit développement ex nihilo, ou bien pars tu d'un
logiciel source existant?
S'agit-il de développer un logiciel libre?
un logiciel qui pourrait plus tard être accédé voire modif ié (via le
versionneur) par une grosse communauté?
(Ainsi, même pour du développement propriétaire, on ne fai t pas les
mêmes choix de versionneurs dans une grosse multi nationale et dans
une toute petite PME)?
S'il y a d'autres développeurs actuellement sur ce projet, à qu els
versionneurs sont-ils habitués?
Quel est le volume prévisible des sources à versionner?
Est-ce que la connectivité est suffisante (par exemple,
accédera-t-on à ce versionneur depuis un autre continent?).
Un autre point très important: il n'est pas du tout nécessaire de
maitriser la totalité des fonctionalités d'un versionneur pour
l'utiliser avec profit. Par exemple concret, je connais mal git, mais
je l'utilise avec satisfaction pour des petits développements
personnels (logiciels ou documentation), et je n'en comprends pas tout.
Le livre "Pragmatic Guide to Git" de Travis Swicegood me parait clair.
Enfin, il faut savoir que changer de versionneur pendant un
développement est une opération délicate (qui peut né cessiter
l'interdiction de l'accès aux sources versionnées pendant plus d'une
journée), et une telle migration doit être planifiée et te stée Ã
l'avance. Ainsi, le compilateur GCC a mis des années à passer d e CVS Ã
SVN.
Il faut aussi savoir si on veut un versionnement centralisé (qui
convient probablement mieux à du logiciel propriétaire dév eloppé par
une équipe locale) ou un versionnement distribué.
Je te conseille donc git (surtout si tu veux un versionnement
distribué, mais je m'en sers aussi pour des projets où je suis tout
seul). La documentation complète est effectivement grosse, mais on e st
pas du tout obligé de la lire en entier. Je ne connais pas du tout l es
subtilités de git mais j'arrive à m'en servir sur des projets n eufs
(c'est probablement plus difficile de migrer vers git depuis autre
chose).
Si tu voulais absoluement un versionnement centralisé (que je te
déconseille), tu pourrais prendre subversion.
Je ne te conseille pas bzr ni mercurial, mais je les connais très mal
et ne m'en sers que pour rapatrier du code source d'un logiciel libre
déposé ailleurs.
Il existe des entreprises qui vendent le service de versionnement. L'un
des avantages, c'est ipso facto de constituer une sauvegarde Ã
distance. Par exemple http://myversioncontrol.com/ ou http://github.com/
A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction
sans en maitriser toutes facettes.
Une question importante est de savoir qui va (au début, et surtout d ans
l'avenir) utiliser ce versionneur. Vas tu l'utiliser tout seul pour un
développement sur lequel tu es le seul à travailler?
Est-ce que les contributeurs futurs à ton développement logicie l seront
proches ou éloignés?
Développes tu sous et pour Linux?
S'agit-il d'une application web?
Est-ce un petit développement ex nihilo, ou bien pars tu d'un
logiciel source existant?
S'agit-il de développer un logiciel libre?
un logiciel qui pourrait plus tard être accédé voire modif ié (via le
versionneur) par une grosse communauté?
(Ainsi, même pour du développement propriétaire, on ne fai t pas les
mêmes choix de versionneurs dans une grosse multi nationale et dans
une toute petite PME)?
S'il y a d'autres développeurs actuellement sur ce projet, à qu els
versionneurs sont-ils habitués?
Quel est le volume prévisible des sources à versionner?
Est-ce que la connectivité est suffisante (par exemple,
accédera-t-on à ce versionneur depuis un autre continent?).
Un autre point très important: il n'est pas du tout nécessaire de
maitriser la totalité des fonctionalités d'un versionneur pour
l'utiliser avec profit. Par exemple concret, je connais mal git, mais
je l'utilise avec satisfaction pour des petits développements
personnels (logiciels ou documentation), et je n'en comprends pas tout.
Le livre "Pragmatic Guide to Git" de Travis Swicegood me parait clair.
Enfin, il faut savoir que changer de versionneur pendant un
développement est une opération délicate (qui peut né cessiter
l'interdiction de l'accès aux sources versionnées pendant plus d'une
journée), et une telle migration doit être planifiée et te stée Ã
l'avance. Ainsi, le compilateur GCC a mis des années à passer d e CVS Ã
SVN.
Il faut aussi savoir si on veut un versionnement centralisé (qui
convient probablement mieux à du logiciel propriétaire dév eloppé par
une équipe locale) ou un versionnement distribué.
Je te conseille donc git (surtout si tu veux un versionnement
distribué, mais je m'en sers aussi pour des projets où je suis tout
seul). La documentation complète est effectivement grosse, mais on e st
pas du tout obligé de la lire en entier. Je ne connais pas du tout l es
subtilités de git mais j'arrive à m'en servir sur des projets n eufs
(c'est probablement plus difficile de migrer vers git depuis autre
chose).
Si tu voulais absoluement un versionnement centralisé (que je te
déconseille), tu pourrais prendre subversion.
Je ne te conseille pas bzr ni mercurial, mais je les connais très mal
et ne m'en sers que pour rapatrier du code source d'un logiciel libre
déposé ailleurs.
Il existe des entreprises qui vendent le service de versionnement. L'un
des avantages, c'est ipso facto de constituer une sauvegarde Ã
distance. Par exemple http://myversioncontrol.com/ ou http://github.com/
A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction
sans en maitriser toutes facettes.
Une question importante est de savoir qui va (au début, et surtout d ans
l'avenir) utiliser ce versionneur. Vas tu l'utiliser tout seul pour un
développement sur lequel tu es le seul à travailler?
Est-ce que les contributeurs futurs à ton développement logicie l seront
proches ou éloignés?
Développes tu sous et pour Linux?
S'agit-il d'une application web?
Est-ce un petit développement ex nihilo, ou bien pars tu d'un
logiciel source existant?
S'agit-il de développer un logiciel libre?
un logiciel qui pourrait plus tard être accédé voire modif ié (via le
versionneur) par une grosse communauté?
(Ainsi, même pour du développement propriétaire, on ne fai t pas les
mêmes choix de versionneurs dans une grosse multi nationale et dans
une toute petite PME)?
S'il y a d'autres développeurs actuellement sur ce projet, à qu els
versionneurs sont-ils habitués?
Quel est le volume prévisible des sources à versionner?
Est-ce que la connectivité est suffisante (par exemple,
accédera-t-on à ce versionneur depuis un autre continent?).
Un autre point très important: il n'est pas du tout nécessaire de
maitriser la totalité des fonctionalités d'un versionneur pour
l'utiliser avec profit. Par exemple concret, je connais mal git, mais
je l'utilise avec satisfaction pour des petits développements
personnels (logiciels ou documentation), et je n'en comprends pas tout.
Le livre "Pragmatic Guide to Git" de Travis Swicegood me parait clair.
Enfin, il faut savoir que changer de versionneur pendant un
développement est une opération délicate (qui peut né cessiter
l'interdiction de l'accès aux sources versionnées pendant plus d'une
journée), et une telle migration doit être planifiée et te stée Ã
l'avance. Ainsi, le compilateur GCC a mis des années à passer d e CVS Ã
SVN.
Il faut aussi savoir si on veut un versionnement centralisé (qui
convient probablement mieux à du logiciel propriétaire dév eloppé par
une équipe locale) ou un versionnement distribué.
Je te conseille donc git (surtout si tu veux un versionnement
distribué, mais je m'en sers aussi pour des projets où je suis tout
seul). La documentation complète est effectivement grosse, mais on e st
pas du tout obligé de la lire en entier. Je ne connais pas du tout l es
subtilités de git mais j'arrive à m'en servir sur des projets n eufs
(c'est probablement plus difficile de migrer vers git depuis autre
chose).
Si tu voulais absoluement un versionnement centralisé (que je te
déconseille), tu pourrais prendre subversion.
Je ne te conseille pas bzr ni mercurial, mais je les connais très mal
et ne m'en sers que pour rapatrier du code source d'un logiciel libre
déposé ailleurs.
Il existe des entreprises qui vendent le service de versionnement. L'un
des avantages, c'est ipso facto de constituer une sauvegarde Ã
distance. Par exemple http://myversioncontrol.com/ ou http://github.com/
A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction
sans en maitriser toutes facettes.
J'ai jeté un oeil, mais je n'ai pas trouvé comment revenir en AR sur un seul
fichier.
J'ai jeté un oeil, mais je n'ai pas trouvé comment revenir en AR sur un seul
fichier.
J'ai jeté un oeil, mais je n'ai pas trouvé comment revenir en AR sur un seul
fichier.
je conseille aussi Git. Il est facile de récupérer une ancienn e version d'un
fichier seulement, avec la commande « git checkout ».
http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one- file
je conseille aussi Git. Il est facile de récupérer une ancienn e version d'un
fichier seulement, avec la commande « git checkout ».
http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one- file
je conseille aussi Git. Il est facile de récupérer une ancienn e version d'un
fichier seulement, avec la commande « git checkout ».
http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one- file
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy
wrote:
> je conseille aussi Git. Il est facile de récupérer une ancienne
> version d'un fichier seulement, avec la commande « git checkout ».
>
> http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-on e-file
Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je
souhaite pouvoir revenir en AR d'un nombre _quelconque_ de révisions
sur n'importe quel fichier
Je tâtonne souvent et je crée des tas de versions différentes d'un
fichier; à la fin, soit le fichier final correspond à mes attentes,
soit je pioche dans plusieurs pour obtenir le final - C'est toute
cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une
fois, je me trompe ptêt: cette partie du dev est peut-être uniquement
du ressort personnel et pas du système de VCS?)
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy
<plessy@debian.org> wrote:
> je conseille aussi Git. Il est facile de récupérer une ancienne
> version d'un fichier seulement, avec la commande « git checkout ».
>
> http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-on e-file
Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je
souhaite pouvoir revenir en AR d'un nombre _quelconque_ de révisions
sur n'importe quel fichier
Je tâtonne souvent et je crée des tas de versions différentes d'un
fichier; à la fin, soit le fichier final correspond à mes attentes,
soit je pioche dans plusieurs pour obtenir le final - C'est toute
cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une
fois, je me trompe ptêt: cette partie du dev est peut-être uniquement
du ressort personnel et pas du système de VCS?)
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy
wrote:
> je conseille aussi Git. Il est facile de récupérer une ancienne
> version d'un fichier seulement, avec la commande « git checkout ».
>
> http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-on e-file
Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je
souhaite pouvoir revenir en AR d'un nombre _quelconque_ de révisions
sur n'importe quel fichier
Je tâtonne souvent et je crée des tas de versions différentes d'un
fichier; à la fin, soit le fichier final correspond à mes attentes,
soit je pioche dans plusieurs pour obtenir le final - C'est toute
cette chaîne que je souhaiterai pouvoir sauvegarder (mais encore une
fois, je me trompe ptêt: cette partie du dev est peut-être uniquement
du ressort personnel et pas du système de VCS?)
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souha iterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette par tie
du dev est peut-être uniquement du ressort personnel et pas du systèm e de VCS?)
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souha iterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette par tie
du dev est peut-être uniquement du ressort personnel et pas du systèm e de VCS?)
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souha iterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette par tie
du dev est peut-être uniquement du ressort personnel et pas du systèm e de VCS?)
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy wrote:je conseille aussi Git. Il est facile de récupérer une ancienne version d'un
fichier seulement, avec la commande « git checkout ».
http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file
Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je souhaite
pouvoir revenir en AR d'un nombre _quelconque_ de révisions sur n'importe quel
fichier
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie
du dev est peut-être uniquement du ressort personnel et pas du système
de VCS?)
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy <plessy@debian.org> wrote:
je conseille aussi Git. Il est facile de récupérer une ancienne version d'un
fichier seulement, avec la commande « git checkout ».
http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file
Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je souhaite
pouvoir revenir en AR d'un nombre _quelconque_ de révisions sur n'importe quel
fichier
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie
du dev est peut-être uniquement du ressort personnel et pas du système
de VCS?)
On Sat, 30 Apr 2011 23:58:12 +0900, Charles Plessy wrote:je conseille aussi Git. Il est facile de récupérer une ancienne version d'un
fichier seulement, avec la commande « git checkout ».
http://stackoverflow.com/questions/692246/git-how-to-undo-changes-of-one-file
Merci pour le link, mais (et c'est ptêt bin là que je me trompe?!) je souhaite
pouvoir revenir en AR d'un nombre _quelconque_ de révisions sur n'importe quel
fichier
Je tâtonne souvent et je crée des tas de versions différentes d'un fichier; à
la fin, soit le fichier final correspond à mes attentes, soit je pioche dans
plusieurs pour obtenir le final - C'est toute cette chaîne que je souhaiterai
pouvoir sauvegarder (mais encore une fois, je me trompe ptêt: cette partie
du dev est peut-être uniquement du ressort personnel et pas du système
de VCS?)
On Sat, 30 Apr 2011 17:21:03 +0200
"Jean-Yves F. Barbier" wrote:
> Je tâtonne souvent et je crée des tas de versions différ entes d'un
> fichier; à la fin, soit le fichier final correspond à mes att entes, soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tro mpe
> ptêt: cette partie du dev est peut-être uniquement du ressort personnel et
> pas du système de VCS?)
>
Les branches de GIT sont faites pour ça (et les tags aussi). On peut
vraiement en avoir beaucoup (même si personnellement je les utilise
peu). Donc il me semble que c'est ton point de vue qui pourrait
changer: tu pourrais raisonner non pas en termes de fichiers
individuels, mais en terme d'arborescence complète, et alors c'est
exactement ce que permet les branches de GIT (il parait que tu pourrais
en avoir des millions).
On Sat, 30 Apr 2011 17:21:03 +0200
"Jean-Yves F. Barbier" <12ukwn@gmail.com> wrote:
> Je tâtonne souvent et je crée des tas de versions différ entes d'un
> fichier; à la fin, soit le fichier final correspond à mes att entes, soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tro mpe
> ptêt: cette partie du dev est peut-être uniquement du ressort personnel et
> pas du système de VCS?)
>
Les branches de GIT sont faites pour ça (et les tags aussi). On peut
vraiement en avoir beaucoup (même si personnellement je les utilise
peu). Donc il me semble que c'est ton point de vue qui pourrait
changer: tu pourrais raisonner non pas en termes de fichiers
individuels, mais en terme d'arborescence complète, et alors c'est
exactement ce que permet les branches de GIT (il parait que tu pourrais
en avoir des millions).
On Sat, 30 Apr 2011 17:21:03 +0200
"Jean-Yves F. Barbier" wrote:
> Je tâtonne souvent et je crée des tas de versions différ entes d'un
> fichier; à la fin, soit le fichier final correspond à mes att entes, soit
> je pioche dans plusieurs pour obtenir le final - C'est toute cette cha îne
> que je souhaiterai pouvoir sauvegarder (mais encore une fois, je me tro mpe
> ptêt: cette partie du dev est peut-être uniquement du ressort personnel et
> pas du système de VCS?)
>
Les branches de GIT sont faites pour ça (et les tags aussi). On peut
vraiement en avoir beaucoup (même si personnellement je les utilise
peu). Donc il me semble que c'est ton point de vue qui pourrait
changer: tu pourrais raisonner non pas en termes de fichiers
individuels, mais en terme d'arborescence complète, et alors c'est
exactement ce que permet les branches de GIT (il parait que tu pourrais
en avoir des millions).