Dev Faq
8
votes

Système de contrôle de version qui garde une trace de fichiers individuels

Jusqu'à présent, j'ai utilisé Git pour gérer mes fichiers de latex. Cependant, Git gère tous les fichiers de latex dans un dossier à la fois.

Ce que je veux, c'est un système de contrôle de version qui

  • me donne une histoire pour chaque fichier séparément
  • me permet de faire des versions anciennes de fichiers individuels sans affecter les autres
  • me permet de faire des branches pour chaque fichier individuel avecoud sur les autres
  • donne des étiquettes aux versions de fichiers individuels

    Peut-être qu'il est possible de le faire avec Git, mais je ne sais pas comment le faire. Il y a donc un bon système de contrôle de version pratique à cette fin?

    Peut-être que je devrais ajouter que j'utilise Linux en tant que système d'exploitation et Emacs comme éditeur de latex.

1 commentaires

On dirait que vous voulez des rcs. (Vous voudrez peut-être reconsidérer, cependant!)

3 Réponses :

-1
votes

Je suis d'accord avec @basileSetarynkevitch - Git est tout ce dont vous avez besoin.

Vous n'avez probablement besoin que d'une belle interface graphique pour GIT, vous pouvez donc voir plus facilement ce qui se passe.

Git est fait pour les programmeurs, pour gérer de grandes quantités de fichiers source, réparties sur plusieurs sous-répertoires. Votre cas d'utilisation est légèrement différent, mais vous pouvez toujours utiliser git git bien pour cela.

Les systèmes de contrôle de la version précoce (RCS, SCCS) ont fait ce que vous venez de décrire dans votre question - mais cela s'est avéré être un désordre, car tout projet réel a généralement plus qu'un seul fichier ;-) et il est facile d'oublier de Vérifiez dans un fichier si chacun est géré par son propre contrôle de version. (Ne faites pas cela)

Ainsi, au lieu de penser "Je dois obtenir la version précédente du fichier A, et une autre version de fichier B", essayez de penser à créer des instantanés à temps de votre projet complet lorsque vous utilisez GIT. par exemple. "Mini-rejets" de votre projet. Si votre projet est latex, vous écrivez un livre ou une publication - peut-être enregistrez-vous vos modifications à chaque fois que vous avez terminé avec une mise à jour, et pensez à cela comme une "mini-version" ..

L'utilisation d'une interface utilisateur graphique pour GIT vous aidera à voir les différences entre les fichiers, les branches, les balises, etc. GIT dispose de fonctionnalités pour la fusion du contenu des versions antérieures d'un fichier dans le fichier actuel - de sorte que ce n'est pas un problème avec GIT. Il existe également des outils pour visualiser et éditer des diffs côte à côte.

2 commentaires

J'utilise Linux. Je n'écris pas un livre ou quelque chose comme ça, j'ai en effet beaucoup de projets indépendants de petits fichiers simples, de sorte que votre point ne s'applique pas vraiment à ma situation ...

Ensuite, dans votre situation, vous devriez avoir un répertoire individuel avec son propre référentiel Git pour chacun de vos projets (chacun de ceux-ci pourraient contenir vos fichiers en latex, ainsi que des illustrations, des images, etc.) en général, vous n'en avez pas un Système de contrôle de version "monolithique" pour tous vos projets lors de l'utilisation de GIT, mais dispose de référentiels de GIT individuels pour chaque projet.

2
votes

Les réponses précédentes sont totalement fud:

  • tout et tout VCS actuel fonctionne avec un ensemble complet de fichiers dans le référentiel (nommez-le comme une modification ou une révision ou ...), donc votre reqs 3-4 aren 't satisfaits comme les branches et les étiquettes sont globaux
  • Seulement des CVS (si nous ne nous souvenons pas de VCS anciens) fonctionne avec un fichier unique comme objet de gestion, mais Je ne recommande fortement pas de penser à utiliser les CVS aujourd'hui

    mais

    • Si tous vos projets sont un fichier simple ???. Tex , vous pouvez utiliser n'importe quel VCS - vous ne verrez aucune différence pour votre cas d'utilisation (IT semble si < / em>)
    • La version incrémentielle de la répétition entière en cas de changement de fichier mono-file n'est pas une mauvaise chose et ne rendez-vous vraiment pas la vie facile - personne ne s'inquiète de la "quelle version de fichier B dois-je utiliser avec la version N de fichier A"
2 commentaires

Avez-vous entendu parler de RCS et de SCCS?

RCS - Oui, SCCS - Non. Avez-vous manqué "actuel" dans mon p.1 ?! Même CVS n'est pas dans la classe "VCS actuelle"

2
votes

RCS toujours disponible et fonctionne toujours bien (et je l'utilise toujours) Le cas d'utilisation est par exemple un répertoire "d'affiches" (avec SVG, pas si génial avec le format binaire) où chaque fichier est grand afin de ne pas vouloir les enrouler dans un seul HG ou un directeur Git où sera énorme.

J'avais l'habitude d'utiliser SCCS BTW mais les RCS beaucoup mieux

0 commentaires

Articles qui pourrait vous intéresser :

Délai d'expiration d'un script bash lorsqu'il n'y a pas de sortie pendant un certain temps
Convertir des images Webp en PNG par la commande Linux
Comment mettre à jour la dernière version de minikube?
Est-il possible de désactiver le délai d'expiration sudo dans le shell actuel?