> For the complete documentation index, see [llms.txt](https://ayakaleaf-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://ayakaleaf-pro.ayaka.space/on-premises/fr/assistance/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 de la Community Edition inclut [la 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 par défaut l’Historique complet du projet. Les projets existants continueront à utiliser l’ancien système d’historique, jusqu’à leur migration. {% hint style="info" %} Si vous passez à `3.5.13` et décidez de revenir à une version antérieure, vous devrez 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. * La prise en charge des versions étiquetées est disponible. * Le système est globalement plus robuste, il y a moins de risque de perte de données. Consultez [la documentation sur 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éez 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 **sharelatex** répertoires. {% endstep %} {% step %} #### Mettre à jour Mettez à jour la version de l’image sharelatex/sharelatex à 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 voudrez empêcher les utilisateurs d’accéder à votre instance pendant la migration, afin d’éviter toute perte de données au cas où vous auriez besoin de restaurer votre sauvegarde. Voir [Migration hors ligne](https://github.com/overleaf/overleaf/wiki/Full-Project-History-Migration/#offline-migration) pour plus d’informations sur la façon 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 actif (api)% ``` {% endcode %} {% endstep %} {% step %} #### Exécutez le script de migration {% code overflow="wrap" %} ```bash # Utilisateurs d’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 du 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 des projets partiellement migrées dans le nouveau système, ce qui permet de réessayer la migration pour les projets individuels qui ont é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 dépasse le seuil de 2 Mo pour l’édition en un fichier non modifiable) Le résultat devrait ressembler à ceci : ```bash Projets migrés : 1 Projets totaux : 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 ayant échoué : 0 Terminé. ``` Si la migration réussit, vous obtiendrez un code de sortie de `0`, et les dernières lignes indiqueront qu’il n’y a eu aucun échec : ```bash Projets ayant échoué : 0 Terminé. ``` Vous pouvez rouvrir l’accès à vos utilisateurs (voir l’étape suivante). En cas d’échec, veuillez consulter la section de dépannage ci-dessous. Vous pouvez toujours 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 alors 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 %} #### Migration hors ligne Pour empêcher les utilisateurs de se connecter pendant que le script de migration de l’historique s’exécute, 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 pourront pas** 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 un certain blocage, ce qui entraînerait une expérience utilisateur dégradée. 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 exécuter la migration pendant des heures moins chargées (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 élevé, vous pouvez exécuter le script et surveiller sa progression, puis décider de continuer à l’exécuter en ligne ou hors ligne selon votre cas particulier. #### Nettoyer les anciennes données d’historique Un script permettant de nettoyer les anciennes données d’historique 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é après que tous les projets ont été migrés. Il peut également être utilisé pour libérer de l’espace pendant 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` collections. MongoDB ne libère pas l’espace disque après la suppression de documents ; il réutilise cet espace pour de futurs documents dans la même collection. Rien n’écrira à nouveau dans ces collections après la migration de l’historique, donc l’espace disque restera inutilisé. Si vous souhaitez 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 les dernières versions correctives de `3.5.x` et les dernières `4.x.x` suppriment les collections comme dernière étape. Vous pouvez relancer le script de nettoyage en toute sécurité. {% endhint %} ### Dépannage Nous ajouterons ici des conseils de dépannage. Veuillez noter que, bien que nous offrions normalement une assistance uniquement aux clients Server Pro, étant donné la nature de cette migration, nous ferons également de notre mieux pour aider les clients CE qui rencontrent des problèmes spécifiques à la migration complète de l’historique du projet. Si le script de migration complète de l’historique du projet échoue (c’est-à-dire se termine avec une erreur ou affiche un nombre non nul de projets ayant échoué), veuillez envoyer les informations suivantes à 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 complète de l’historique 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 totaux : (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 à l’e-mail. Vous pouvez les trouver à `/var/log/sharelatex` dans le `sharelatex` conteneur et les exporter comme ceci : ```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 supprimer toute information sensible des fichiers journaux avant de les joindre. #### Recherche d’arbres de fichiers endommagés La migration peut échouer pour les projets qui ont une arborescence de fichiers 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 de 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" CHEMIN INCORRECT : 123456789012345678901234 rootFolder.0.1.2.3 CHEMIN INCORRECT : 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 %} #### Retour 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://ayakaleaf-pro.ayaka.space/on-premises/fr/assistance/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.