Meilleures approches pour gérer les versions des fichiers « bundles » Mac

Question

Vous savez donc que de nombreuses applications Mac utilisent des « bundles » :Cela ressemble à un seul fichier pour votre application, mais il s’agit en fait d’un dossier contenant de nombreux fichiers.

Pour qu'un système de contrôle de version puisse gérer cela, il doit :

• extraire tous les fichiers d'un répertoire afin que l'application puisse les modifier si nécessaire
• à l'enregistrement,
  • valider les fichiers qui ont été modifiés
  • ajouter de nouveaux fichiers créés par l'application
  • marquer comme supprimés les fichiers qui ne sont plus là (puisque l'application les a supprimés)
  • gérer cela comme un seul changement atomique

Avez-vous des idées sur la meilleure façon de gérer cela avec les systèmes de contrôle de version existants ?L'un des systèmes de gestion de versions est-il plus compétent dans ce domaine ?

Answer 1

Pour les systèmes SCM distribués comme git et mercurial, cela ne devrait pas poser de problème, comme Matthew l'a mentionné.

Si vous devez utiliser un SCM centralisé comme Subversion ou CVS, vous pouvez alors compresser (archiver) vos bundles avant de les archiver dans le contrôle de code source.Cela peut être douloureux et nécessite une étape supplémentaire.Il existe un bon article de blog à ce sujet sur Tapestry Central :

Offres groupées Mac OS X vs.Subversion

Cet article présente un script Ruby qui gère l'archivage pour vous.

Answer 2

Mercurial dans des versions particulières basées sur des fichiers et non sur une structure de répertoires.Par conséquent, votre arbre de travail, qui est un référentiel à part entière, ne crache pas de dossiers .svn à chaque niveau.

Cela signifie également qu'un répertoire remplacé, comme une application ou un autre bundle, trouvera toujours son contenu avec des noms de fichiers particuliers sous contrôle de révision.Les noms de fichiers sont surveillés, pas les inodes ou quoi que ce soit d'extraordinaire de ce genre !

Évidemment, si un nouveau fichier est ajouté au Bundle, vous devrez l'ajouter explicitement à votre référentiel.De même, la suppression d'un fichier d'un Bundle doit être effectuée avec un « hg rm ».

Il n'existe pas encore d'interface graphique Mercurial décente pour OS X, mais si tout ce que vous faites est d'ajouter/valider/fusionner, il n'est pas si difficile d'utiliser une ligne de commande.

Answer 3

Une mise à jour du futur :

Si je me souviens bien, le problème avec la gestion des bundles dans SVN était que tous les dossiers .svn étaient effacés à chaque fois que vous créiez un bundle.Cela ne devrait plus poser de problème, maintenant que SVN stocke tout dans un seul dossier .svn à la racine.

Answer 4

Ramener ce fil à la lumière du jour, depuis l'iWork d'octobre 2013 (Pages 5.0 etc.) ne permet plus le stockage dans un « fichier plat » (zippé), mais uniquement sous forme de bundles.

Le problème n'est pas la création de dossiers cachés de contrôle de version à l'intérieur de telles structures (enfin, pour svn, c'est le cas), mais comme Marque dit dans la question :obtenir une mise à jour automatique et atomique des fichiers ajoutés ou supprimés (par l'application, dans ce cas iWork), donc je n'aurais pas besoin de le faire manuellement.

De toute évidence, iWork et Apple ne sont gênés que par la convivialité d'iCloud.Pourtant, j'ai de véritables arguments pour stocker .pages, .numbers et .keynote dans un dépôt Mercurial.Après la mise à jour, tout explose.Ce qu'il faut faire?

Addenda:

Trouvé 'hg addremove' ça fait l'affaire pour moi.

$ hg help addremove
hg addremove [OPTION]... [FILE]...

add all new files, delete all missing files