[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: versioning system (VCS)



On Sat, 30 Apr 2011 15:39:22 +0200
"Jean-Yves F. Barbier" <12ukwn@gmail.com> wrote:

> 
> 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.

Tu n'as pas indiqué quel genre de développement c'est.
 
> 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:)

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? Est-ce que les
contributeurs futurs à ton développement logiciel 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? Ou
un logiciel qui pourrait plus tard être accédé voire modifié (via le
versionneur) par une grosse communauté? (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)? S'il y a d'autres développeurs actuellement sur ce projet, à
quels versionneurs sont-ils habitués? Quel est le volume prévisible des
sources (ou autres, on pourrait aussi versionner des photos.. etc...) à
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 testée à
l'avance. Ainsi, le compilateur GCC a mis des années à passer de CVS à
SVN.

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é.

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). 

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/

Pour du logiciel libre GPL, on trouve assez facilement des versionneurs
gratuits.

A priori je te conseille git, mais j'avoue l'utiliser avec satisfaction
sans en maitriser toutes facettes.

Cordialement
-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***


Reply to: