----- "Patrice Karatchentzeff" <patrice.karatchentzeff@???> a écrit :
> Le 9 juin 2011 08:41, Yves Martin <ymartin1040@???> a écrit :
>
> [...]
>
> Je rebondis juste là-dessus : le reste, je suis d'accord.
>
> > Je suis d'accord qu'un serveur de build / intégration continue ne se
> backup pas. Une image après setup ou mise à jour suffit.
> >
> > Dans mon cas ce sont des stations de développement. C'est limite
> parce que je peux laisser des travaux en attente de commit plusieurs
> jours...
> > Et je ne vais pas faire un commit "provisoire" (incomplet ou qui ne
> compile pas) juste pour le backup qui est derrière.
>
> Pas d'accord. Une station de dév, c'est comme un serveur de
> build|IC|etc. Ça ne se backupe pas plus. Si les gars ont des
> développements qui durent et qui doivent être backupés, ça se commite
> dans une branche spécifique pour ne pas pourrir le tronc commun¹
> (et/ou les builds|IC associés). C'est du bon usage de la gconf.
> Sinon,
> c'est du... mauvais usage du backup : tu pallies leur manque de
> compréhension de l'outil. Il vaut mieux leur apprendre à se servir
> correctement de la gconf...
>
> PK
>
> ¹ : de plus, il est rare que cela soit coûteux en place : le dév,
> c'est essentiellement du fichier texte... commiter, même plusieurs
> centaines de fichiers sources, cela n'occupe rien dans un dépôt en
> gconf...
Je rebondis aussi car je comprends tout cela très bien et le pratique
quotidiennement.
Tout d'abord, je confirme que c'est coûteux - parce qu'en général
une copie de travail mélange des contenus non modifiés et des résultats
de build, des logs, des dump de base - en général dans les exclusions
de l'outil de gconf... et des contenus modifiés par rapport à celui
connu du dépôt et je les veux dans mon backup quotidien !
Ensuite l'idée de la branche de développement ("new feature branch"
ou "per user branch") peut être pratique... sauf quand il faut s'amuser
à en marger une tripotée (et après il faut faire le ménage quand elles
ne servent plus)
Pour l'instant mon usage actuel c'est Subversion, sur trunk/, des
update réguliers pour faire au fil de l'eau le "merge" avec les modifications
des autres jusqu'au moment où tout est bon: compile, testé, documenté => commit.
OK - tu vas me répondre d'utiliser Git qui au passage va consommer 50 fois
l'espace utilisé par Subversion, de remplacer mes "update" par "git pull",
de merger ma branche perso à chaque fois...
Bref, c'est comme ça - je préfère Subversion - et maintenant je veux faire des
backups de mes copies de travail sans inclure les produits de génération.
C'est décidé, je fais un patch dans rsync comme ça j'aurai ce que je veux !
--
Yves Martin
