Re: versioning system (VCS)
On Sat, 30 Apr 2011 16:07:17 +0200, Basile Starynkevitch
<basile@starynkevitch.net> wrote:
> Une question importante est de savoir qui va (au début, et surtout dans
> l'avenir) utiliser ce versionneur. Vas tu l'utiliser tout seul pour un
> développement sur lequel tu es le seul à travailler?
Vi
> Est-ce que les contributeurs futurs à ton développement logiciel seront
> proches ou éloignés?
Les 2
> Développes tu sous et pour Linux?
Vi, mais avec poss d'extension à d'autres OS (par contribs)
> S'agit-il d'une application web?
Non
> Est-ce un petit développement ex nihilo, ou bien pars tu d'un
> logiciel source existant?
Ex-nihilo
> S'agit-il de développer un logiciel libre?
Je ne sais pas encore (si c'est non, c'est parce que je souhaiterai exclure
toute organisation gouvernementale & afférente)
> un logiciel qui pourrait plus tard être accédé voire modifié (via le
> versionneur) par une grosse communauté?
Non, tout au plus certains devs choisis
> (Ainsi, même pour du développement propriétaire, on ne fait pas les
> mêmes choix de versionneurs dans une grosse multi nationale et dans
> une toute petite PME)?
Plutôt une chtite PME
> S'il y a d'autres développeurs actuellement sur ce projet, à quels
> versionneurs sont-ils habitués?
Non, pas avant une version 0.99
> Quel est le volume prévisible des sources à versionner?
Tout au plus qq mégas (seulement du code en texte et qq icones/images (figées))
> Est-ce que la connectivité est suffisante (par exemple,
> accédera-t-on à ce versionneur depuis un autre continent?).
Oui (fibre)
> 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.
J'ai jeté un oeil, mais je n'ai pas trouvé comment revenir en AR sur un seul
fichier.
> 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 testée à
> l'avance. Ainsi, le compilateur GCC a mis des années à passer de CVS à
> SVN.
C'est ben pour ça que je pose la question ici: j'ai lu quelques articles sur
la toile et tous disent cela.
> Il faut aussi savoir si on veut un versionnement centralisé (qui
> convient probablement mieux à du logiciel propriétaire développé par
> une équipe locale) ou un versionnement distribué.
C'est une pierre d'achoppement: pour certaines parties, je souhaite rester
seul maître de l'incorporation ou non des devs externes; mais pour d'autres
(où je suis peu à l'aise) il est possible que certains pans soient
entièrement externalisés.
> 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 est
> pas du tout obligé de la lire en entier. Je ne connais pas du tout les
> subtilités de git mais j'arrive à m'en servir sur des projets neufs
> (c'est probablement plus difficile de migrer vers git depuis autre
> chose).
Comme dit plus haut et parce que je procède souvent par tâtonnements, je
dois-être en mesure de pouvoir revenir en AR d'une ou plusieurs versions
seulement sur certains fichiers, mais c'est justement ce que je n'ai pas
trouvé dans git.
> Si tu voulais absoluement un versionnement centralisé (que je te
> déconseille), tu pourrais prendre subversion.
Non, je ne pense pas (et puis, qui peut le plus peut le moins:)
> 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.
Mercurial semble encore plus abscon que git (mais testé il-y-a un certain
temps), quant'à Bazaar je ne connais pas mais il existe en tant que package.
> 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/
Pour l'instant, non (j'ai la possibilité d'aller pêcher dans le svr alimenté
en fibre à partir de chez moi, donc il est facile de faire un rsync régulier.)
> A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction
> sans en maitriser toutes facettes.
Je veux bien, mais à la condition exprimée ci-dessus.
--
Your analyst has you mixed up with another patient. Don't believe a
thing he tells you.
Reply to: