Mon problème d'origine est que j'ai un répertoire où j'écris divers scripts. Chacun d'entre eux est indépendant des autres, et généralement à un dossier. Je veux avoir des messages qui leur sont appliqués, mais j'ai les problèmes / exigences suivants:
est-ce possible?
Je préférerais le faire dans certains VC distribués traditionnels (une solution utilisant Mercurial serait préférable, mais je ne suis pas corrigé).
edit: La solution doit être libre (au moins "comme dans la bière") et une plate-forme inter-plate-forme (au moins Win32 & Linux).
liés, mais n'a pas aidé:
7 Réponses :
Je ne peux penser que ces deux systèmes de version de version légers:
1) Utilisation de Dropbox avec la mise à niveau Pack-Rat, afin de conserver l'historique complet de versions de chaque fichier automatiquement sauvegardé et avec la possibilité d'être partagée avec plusieurs utilisateurs Dropbox: https://www.dropbox.com/help/113
Si vous avez plusieurs machines gérées par le même utilisateur (vous), la synchronisation serait automatique. De plus, si les machines sont dans le même réseau local, Dropbox est suffisamment intelligente pour synchroniser les fichiers sur le réseau local, de sorte que les gros fichiers ne soient pas un inquiétude.
2) Utilisation d'une éditeur de texte au courant des "versions" pour Mac OS X Lion . Je m'attendrais à ce que texmate, coda et autres éditeurs de code Mac populaires soient mis à jour pour prendre en charge cette fonctionnalité lorsque Lion est libérée.
Ah, merci pour des idées; Malheureusement, certaines exigences qui m'ont manquent subjectivement lors de la rédaction de la question. Je vais devoir mettre à jour le texte pour les rendre visibles.
Ces exigences semblent jolies "spéciales" à moi, voici une solution à égalité avec eux ^^
Vous pouvez utiliser deux VC complètement différents, dans le même répertoire. Même deux "instances" de SVN pourrait fonctionner: SVN stocke ses métadonnées dans un répertoire appelé bien sûr, vous devrez vous cacher ou ignorer les scripts ou les dossiers étrangers de chaque VCS ... Ajoutée:
Cela ne représente que deux scripts dans un dossier et nécessite une VC supplémentaire par script au-delà de cela, donc si vous envisagez même cette voie et avez besoin de plus de référentiels, renommez chaque métadir et utilisez un script pour le renommer avant de la mise à jour: < Pré> xxx .svn et a (pour des raisons historiques concernant ASP) l'option d'utilisation _svn . La liste de répertoires doit ressembler à ce
Questions étranges. Réponses étranges. +1 :)
On dirait que j'ai manqué cette réponse qui apparaissant juste avant de commencer à écrire ma propre description de la même idée :) Cela dit, je préférerais toujours avoir une telle solution "pré-emballée" pour avoir à écrire mon propre script pour la mettre en œuvre.
@Akavel je ne pense pas qu'il y a quelque chose de pré-emballé pour ce scénario. Si un simple shellscript ne le fera pas, la meilleure solution suivante serait de laisser tomber l'une des exigences.
OK, à compter d'aujourd'hui, cette idée sonne la plus intéressante pour moi, lorsqu'elle est considérée avec un niveau d'automatisation en haut ( hashtable: nom_fichier-> repoïne + auto-dépo?). Bien que je devrais probablement vérifier également l'extension «Convert Mercurial Convert», et il a des chances de prouver plus pratique. Merci à tout le monde qui a contribué des idées! :)
Pourquoi ne créez-vous pas simplement une branche distincte (dans le sens Sense) pour chaque (s) script (S)?
Vous pouvez les développer individuellement comme vous s'il vous plaît. La commutation d'une branche ne vous indiquera que les scripts de cette branche. C'est une sorte de répertoires, mais géré par le système de contrôle de la version. Si vous souhaitez plus tard cueillir une succursale dans un autre référentiel, vous pouvez le faire et si vous souhaitez combiner deux scripts dans un seul projet, vous pouvez le faire également. Les copies sur le point de la machine différente pourraient être un problème, mais vous pouvez cloner la branche qui vous intéresse et vous devez travailler pour vous.
Le "commutation à une succursale vous montrera que seuls les scripts de cette branche" par pièce ressemble à la question principale pour moi: si je comprends bien, alors avant d'appeler l'un des scripts, je devrais me rappeler dans quelle branche il a été stocké et passez à cette branche. Outre des inconfortables d'avoir à émettre une commande supplémentaire à chaque fois: que si je voulais obtenir des résultats de tuyau d'un script à travers un autre script (d'une autre branche)?
Vous pouvez éviter le problème de nommage en nommant les branches après vos scripts. Le deuxième point était quelque chose que vous n'avez pas mentionné dans vos exigences d'origine et que cela indique que ces scripts sont utilisables ensemble, ce qui est un argument pour les mettre dans un seul référentiel.
Le "premier" script pourrait être très spécifique (avec la connaissance de certaines subordonnées de format de fichier particulier), tandis que le "deuxième" haut général (comme "WC"). Je serais très intéressé de déplacer la seconde entre ordinateurs, tandis que le premier peut être complètement inutile dans un environnement différent.
Logique. Je serais plus enclin à les former ensemble en tant que "utils" repo (semblable à la manière dont je fais avec mon repo de configuration contenant mes fichiers de configuration EMACS et ZSH).
Mise à jour (2016): strong> Apparemment, un gars nommé Cosmin Apreuesei a créé un outil nommé Multigit strong>, qui semble mettre en œuvre ce que je souhaitais dans cette question! Si vous le lisez jamais, merci beaucoup cosmin! EM> J'ai commencé à utiliser votre outil cette année et à le trouver génial em>. P>.
Je commence à penser à une sorte de superposition sur la mercurielle / git / ... qui garderait un couple "handicapé" méta-répertoires de référentiel, disons: P>
mv .hgN .hg hg commit FILENAME mv .hg .hgN
J'ai essayé de le faire en réinitialisant de manière dynamique la variable git_dir, mais je le pensais inélégant.
@Noufal: Souhaitez-vous élaborer un peu plus? Qu'est-ce que git_dir? Pourquoi le penseriez-vous inélégant, quels inconvénients voyez-vous?
Je suppose que l'idée fondamentale d'avoir plusieurs référentiels dans un seul répertoire ne m'a pas appelé. En outre, j'ai essayé de conserver les repos dans un sous-répertoire séparé que Git n'aimait pas.
Une autre proposition pour ma propre considération est " Utilisation de convertir pour décomposer votre référentiel "Article sur hgtip.com . Il échoue comme une solution "autonome", mais pourrait être utile comme une addition au " mv .hgn .hg / déplacer .svn-script1 .svn " Idée. < / p>
Que diriez-vous d'un compromis entre 1 et 2? Au lieu d'un dossier + Repo pour chaque script, pouvez-vous les regrouper dans des groupes lâchés, tels que "base de données", "sauvegarde", etc., puis faire un dossier + repo pour chaque groupe? Ensuite, si vous clonez un repo sur une autre machine, vous tirez uniquement un plus petit nombre de fichiers non liés. (Est-ce que la bande passante / l'espace de drive est vraiment une préoccupation?) Pour moi, cela semble plus simple que toutes les autres suggestions jusqu'à présent.
(Techniquement, cette approche répond à vos exigences car (1) Chaque script n'est pas dans son propre répertoire, (2) Tous les scripts ne sont pas dans le même référentiel, et (3), vous pouvez facilement le faire avec des DVC populaires. : D)
Malheureusement, j'aurais toujours un problème avec cette approche, car cela vous obligeait à faire "la catégorisation prématurée": avant que je puisse commencer à coder, je devrais penser dur quelle catégorie il va appartenir à. Cela pourrait ne pas être si clair (pour moi) à ce stade, et si je faisais mon choix à tort, je serais puni par (Afaik) de ne pas pouvoir bouger facilement le script (avec l'histoire) entre les repos plus tard, pour ajuster la décision. En ce qui concerne la simplicité, je pense que je préférerais même une solution techniquement plus compliquée, tant qu'elle est plus simple de Utilisation perspective.
Malheureusement, je ne pense pas que vous allez trouver une solution qui fait exactement ce que vous voulez, mais je vous souhaite bonne chance. Puisque vous êtes opposé à une pré-organisation, mon conseil serait de simplement mettre tous les dossiers en un seul repo mercurial, puis si la journée vient que vous décidez que vous décidez un ou plusieurs d'entre eux devraient être seuls, utilisez HG's Convertissez une extension avec une filemap pour diviser le repo.
Je pense que la solution avec "Convertir une extension" est également une bonne idée et je vais devoir vérifier, surtout en ce qui concerne ce qui se passe dans l'histoire. Si cela s'est avéré remplir mes désirs, je pense que cela correspondrait à l'idée «MV» .hgn .hg », et ensemble, ils ont le potentiel de faire le« combo d'or ».
Vous pouvez créer plusieurs répertoires de référentiels cachés et Symlink puis pour activer l'un ou l'autre juste faire: vous pourriez facilement Créez une commande bash pour le faire. Donc, vous pouvez plutôt écrire quelque chose comme note: Mac ne pas semble prendre en charge .hg à ce que vous voulez être actif. Donc, si vous avez deux référentiels, créez des répertoires pour eux: activate-repo production , qui exécuterait ln -sf .hg_production .hg . ln -sf afin que vous devrez plutôt faire:
Cela pourrait vous aider si vous expliquez pourquoi vous avez ces deux objectifs contradictoires: ensemble au même endroit; Version distincte des référentiels de contrôle. En pensant à une installation de paquet sur Linux, il y aurait un emplacement pour l'installation à installer, puis dans le cadre de l'installation, ils seraient liés à un emplacement commun pour l'accès (c'est-à-dire. / Usr / bin). Pourrait-il s'agir d'un processus d'installation ou de déploiement vous permet de répondre à vos objectifs?
Comme je l'ai dit, j'en ai besoin pour stocker des scripts ad-hoc que j'écris à diverses fins (vraiment très général - un peu
$ home / bin dir). Votre idée est intéressante, mais malheureusement plusieurs inconvénients pour moi: la manipulation d'un DIR distincte et d'un processus de déploiement est souvent trop (mental). (Un script peut être un simple double liner); De plus, je pense que ce déploiement deviendrait un problème si le script souhaitait plus tard pour grandir et inclure certaines dépendances stockées dans un subdir.@splonk: Merci pour les souhaits. Veuillez vous abstenir de Personam commentaires.
Ne l'entend pas comme une attaque personnelle. Pour clarifier: Comme la solution s'écarte de la norme, le coût augmente (le pire des cas échéant, vous créez votre propre VC). Recommandant que vous équilibrez cela contre le coût de la réalisation de vos objectifs d'une autre manière. C'est tout.
@splonk: Merci pour la clarification. Quant à vos arguments, ce sont en fait les raisons pour lesquelles j'ai posé la question du tout - que j'ai trouvé le problème difficile pour moi et espérais que quelqu'un d'autre sait, ou est plus intelligent et le trouve plus facile de inventer, une solution (et peut-être même l'avoir déjà mise en œuvre).
Si les scripts sont totalement indépendants, pourquoi devraient-ils être dans le même répertoire? Semble pas logique pour le faire arranger de cette façon. Et si le répertoire qu'ils partagent doivent être sur le chemin de recherche, sépériant leur lieu de développement et utiliser une étape d'installation qui les copie à l'emplacement final semble plus appropriée.