> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/fr/support/support-guides/full-project-history-migration.md). # (Migration v3.5.13) Migration de l'historique complet du projet ## Migration complète de l’historique des projets Le `3.5.x` la version Community Edition inclut le [fonctionnalité Historique complet du projet](https://www.overleaf.com/learn/latex/Using_the_History_feature) qui est déjà disponible dans notre offre SaaS, [overleaf.com](http://overleaf.com/) Après la mise à niveau de votre instance vers Overleaf CE `3.5.13`, tous les nouveaux projets utiliseront l’Historique complet du projet par défaut. Les projets existants continueront d’utiliser l’ancien système d’historique jusqu’à leur migration. {% hint style="info" %} Si vous mettez à niveau vers `3.5.13` et décidez de revenir à une version antérieure, vous devez alors restaurer à partir d’une sauvegarde complète du système. L’historique des projets créés dans `3.5.13` n’est pas compatible avec les versions antérieures d’Overleaf CE. {% endhint %} Le nouvel Historique complet du projet apporte plusieurs améliorations pour les utilisateurs : * Il suit les modifications dans les fichiers binaires, ce qui n’est pas pris en charge par l’ancien système. * Les versions étiquetées sont prises en charge. * Le système est en général plus robuste, il y a moins de risques de perte de données. Consultez [la documentation de l’Historique complet du projet](https://www.overleaf.com/learn/latex/Using_the_History_feature) pour plus d’informations sur l’historique complet du projet. ### Migration des projets existants {% stepper %} {% step %} #### Créer une sauvegarde Créez une [sauvegarde complète](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) de votre instance avec un instantané cohérent des **mongo**, **redis** et **conteneur sharelatex.** répertoires. {% endstep %} {% step %} #### Mettez à jour Mettez à jour la version de l’image sharelatex/sharelatex vers 3.5.13. Toolkit : utilisez le `$ bin/upgrade` script pour mettre à niveau le toolkit vers la dernière version et modifiez **config/version** en 3.5.13. {% endstep %} {% step %} #### Démarrer l’instance Idéalement, vous devriez empêcher les utilisateurs d’accéder à votre instance pendant la migration, afin d’éviter une perte de données au cas où vous auriez besoin de restaurer votre sauvegarde. Consultez [la migration hors ligne](https://github.com/overleaf/overleaf/wiki/Full-Project-History-Migration/#offline-migration) pour plus d’informations sur la manière de procéder. {% endstep %} {% step %} #### Attendez que tous les services soient démarrés et opérationnels Attendez que tous les services soient démarrés et opérationnels (voir la commande ci-dessous) {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status" web sharelatex est opérationnel (api)% ``` {% endcode %} {% endstep %} {% step %} #### Exécutez le script de migration {% code overflow="wrap" %} ```bash # utilisateurs de Overleaf Toolkit : $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file" # utilisateurs de l’ancien docker-compose.yml : $ docker exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file" ``` {% endcode %} `--force-clean` efface les données d’historique de projet partiellement migrées dans le nouveau système, ce qui permet de retenter la migration pour les projets individuels ayant échoué lors des tentatives précédentes ; `--fix-invalid-characters` remplace les caractères non imprimables qui ne sont pas pris en charge par le nouveau système d’historique ; `--convert-large-docs-to-file` convertit les documents dont la taille modifiable dépasse le seuil de 2 Mo en fichier non modifiable) La sortie devrait ressembler à ceci : ```bash Projets migrés : 1 Projets au total : 51 Projets restants : 51 Nombre total d’enregistrements d’historique à migrer : 98 Démarrage de la migration... Migration du projet : 63d29b5772dd80015a81bffe résultat de la migration { upgraded: true, historyType: 'NoneWithoutConversion' } Migration du projet : 63d29c2e72dd80015a81c0a2 résultat de la migration { upgraded: true, historyType: 'NoneWithoutConversion' } // … Migration terminée ================== Projets migrés : 51 Projets en échec : 0 Terminé. ``` Si la migration réussit, vous obtiendrez un code de sortie de `0`, ainsi que les dernières lignes indiquant qu’il n’y a eu aucun échec : ```bash Projets en échec : 0 Terminé. ``` Vous pouvez rouvrir l’accès à vos utilisateurs (voir l’étape suivante). S’il y a des échecs, veuillez consulter la section de dépannage ci-dessous. Vous pouvez quand même rouvrir le site si les problèmes ne sont pas résolus immédiatement, et les projets non migrés resteront sur l’ancien système d’historique. {% endstep %} {% step %} #### Rouvrir le site Si vous avez choisi d’effectuer une migration hors ligne, vous devrez rouvrir le site. Si vous êtes toujours connecté, vous devrez : 1. Cliquez sur le **Admin** bouton et choisissez **Gérer le site** 2. Cliquez sur le **Ouvrir/Fermer l’éditeur** onglet 3. Cliquez sur le **Rouvrir l’éditeur** bouton Si vous avez fermé votre navigateur, vous devrez redémarrer le site avec `$ bin/up`. {% endstep %} {% endstepper %} #### la migration hors ligne Pour empêcher les utilisateurs de se connecter pendant l’exécution du script de migration de l’historique, veuillez suivre ces étapes : * Connectez-vous à votre instance Overleaf avec un compte administrateur * Cliquez sur le **Admin** bouton et choisissez **Gérer le site** * Cliquez sur le **Ouvrir/Fermer l’éditeur** onglet * Cliquez sur le **Fermer l’éditeur** bouton * Cliquez sur le **Déconnecter tous les utilisateurs** bouton Une fois cela fait, si des utilisateurs sont connectés, ils seront redirigés vers la page de maintenance, et tout nouvel utilisateur visitant la page de connexion verra la page de maintenance et **ne le fera pas** pourra se connecter. #### Migration en ligne Il est possible d’exécuter les scripts de migration pendant que l’application est encore en cours d’exécution. Il y a quelques points à prendre en compte : * Le processus de migration est gourmand en CPU, vous devez surveiller l’utilisation des ressources pendant l’exécution du script. * Avec une valeur élevée de `--concurrency` , la boucle d’événements de certains services (`track-changes` en particulier) peut subir des blocages, ce qui entraînerait une dégradation de l’expérience UX. Nous recommandons de commencer avec la valeur par défaut `--concurrency=1` . * Vous pouvez arrêter le script à tout moment. Le relancer reprendra la migration là où vous l’avez laissée. C’est utile si vous préférez lancer la migration pendant les heures creuses (par exemple la nuit). Notre recommandation est de fermer le site et d’exécuter la migration hors ligne pendant une fenêtre de maintenance lorsque votre nombre de projets est inférieur à 1000 projets (`db.projects.count()`). Si le nombre de projets est important, vous pouvez exécuter le script et suivre sa progression, puis décider s’il faut continuer à l’exécuter en ligne ou hors ligne selon votre cas particulier. #### Nettoyer les données de l’historique hérité Un script de nettoyage des données de l’historique hérité a été ajouté dans Server Pro `3.5.6`, `4.0.6` et `4.1.0`. {% code overflow="wrap" %} ```bash bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/history/clean_sl_history_data.js" ``` {% endcode %} Le script peut être exécuté une fois que tous les projets ont été migrés. Il peut aussi servir à libérer de l’espace lors d’une migration en ligne. {% hint style="info" %} Dans Server Pro avant la version 3.5.13, le script supprime le contenu de `docHistory` et `docHistoryIndex` des collections. MongoDB ne libère pas l’espace disque après suppression de documents ; il réutilise cet espace pour de futurs documents dans la même collection. Plus rien n’écrira dans ces collections après la migration de l’historique, donc l’espace disque restera inutilisé. Si vous voulez rendre à nouveau l’espace disque disponible, vous pouvez mettre à niveau vers Server Pro 3.5.13 (si vous utilisez encore la version 3.x) ou Server Pro 4.2.5 (si vous utilisez la version 4.x) et relancer le script de nettoyage. Le script de nettoyage inclus dans Server Pro dans les dernières versions correctives de `3.5.x` et les dernières `4.x.x` suppriment les collections comme dernière étape. Il est sans danger de relancer le script de nettoyage. {% endhint %} ### Dépannage Nous ajouterons ici des conseils de dépannage. Veuillez noter que, même si nous offrons normalement l’assistance uniquement aux clients Server Pro, compte tenu de la nature de cette migration, nous ferons également de notre mieux pour aider les clients CE qui rencontrent des problèmes propres à la migration vers l’historique complet du projet. Si le script de migration vers l’historique complet du projet échoue (c.-à-d. se termine avec une erreur ou affiche un nombre non nul de projets en échec), veuillez envoyer les détails suivants à notre équipe d’assistance par e-mail [support+historymigration@overleaf.com](mailto:support+historymigration@overleaf.com?subject=Full%20project%20history%20migration%20problem\&body=Instance%20Type%3A%20CE%20or%20Server%20Pro%20%28delete%20as%20appropriate%29%0A%0AInstallation%20Type%3A%20Overleaf%20toolkit%20or%20docker-compose.yml%20or%20other%20%28delete%20as%20appropriate%29%0A%0AScript%20output%3A%0A%0Abin%2Fdoctor%20output%20%28if%20using%20toolkit%29%3A%0A), en précisant : Objet : problème de migration de l’historique complet du projet * Type d’instance : CE ou Server Pro (supprimez la mention inutile) * Type d’installation : Overleaf Toolkit ou `docker-compose.yml` ou autre (supprimez la mention inutile) * Version : 3.5.x (toolkit : `$ cat config/version`) * Sortie du script de migration (qui devrait se trouver dans le conteneur sous `/overleaf/services/web`) * Projets migrés : (selon la sortie du script de migration) * Projets au total : (selon la sortie du script de migration) * Projets restants : (selon la sortie du script de migration) * Durée de la migration : * `bin/doctor` sortie (lors de l’utilisation du toolkit) * Version du toolkit : `$ git rev-parse HEAD` (lors de l’utilisation du toolkit) Pensez à joindre les fichiers journaux des `history-v1`, `project-history` et `track-changes` services au courriel. Vous pouvez les trouver dans `/var/log/sharelatex` à l’intérieur du `conteneur sharelatex.` conteneur et les exporter ainsi : ```bash $ docker cp sharelatex:/var/log/sharelatex/history-v1.log history-v1.log $ docker cp sharelatex:/var/log/sharelatex/project-history.log project-history.log $ docker cp sharelatex:/var/log/sharelatex/track-changes.log track-changes.log ``` Veuillez masquer toute information sensible dans les fichiers journaux avant de les joindre. #### Recherche d’arbres de fichiers corrompus La migration peut échouer pour les projets dont l’arborescence de fichiers est mal formée (par exemple, lorsque les noms de fichiers sont vides). Vous pouvez trouver une liste de ces problèmes à l’aide du `find_malformed_filetrees` script qui vérifie tous les projets dans la base de données : {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js" BAD PATH: 123456789012345678901234 rootFolder.0.1.2.3 BAD PATH: 123456789012345678901234 rootFolder.0.4.5.6 ... ``` {% endcode %} Pour corriger les chemins invalides, utilisez le `fix_malformed_filetree` script, en exécutant la commande une fois pour chaque chemin incorrect : {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.1.2.3" $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.4.5.6" ... ``` {% endcode %} #### Rétrogradation des projets de l’historique complet du projet vers l’historique hérité S’il existe un projet qui a été migré vers l’historique complet du projet mais que vous souhaitez revenir à l’historique hérité, utilisez le `downgrade_project` script comme suit : {% code overflow="wrap" %} ```bash $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; PROJECT_ID=YOUR ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/fr/support/support-guides/full-project-history-migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.