Donc on doit prendre le dernier objet du dernier changeset l'importer dans JOSM avec les objet liés et faire les modifications au fur et à mesure des versions (ou successions de versions) des éléments dans ce cas?! Ça va être sacrément long... sachant qu'en plus à chaque sauvegarde, comme le disait @Pieren, Crée une nouvelle version de l'objet...
Est ce qu'on pourrait avoir des exemples concrets afin de mieux comprendre les différents problèmes que l'on risque de rencontrer et comment les résoudre? Merci Peut-on aussi considérer un retour à une date donnée si il n'y a pas eu d'autre modification d'utilisateur pendant un certains délais sur un ensemble de relation? Ces histoires de revert c'est vraiment pas simple. Jérôme Le 20 septembre 2014 00:51, Philippe Verdy <[email protected]> a écrit : > Le 19 septembre 2014 17:46, Pieren <[email protected]> a écrit : > >> 2014-09-18 21:37 GMT+02:00 <[email protected]>: >> >> > pour les revert: >> > si on veut faire un revert de plusieurs changesets, on commence par >> faire le revert du plus récent >> >> Attention, même en faisant le revert dans l'ordre inverse, on ne >> retrouvera pas les données antécédentes sans conflits. En effet, si le >> vandale a créé deux versions d'un élément (par ex, v1 -> v2 puis v2 -> >> v3), le premier revert crée une nouvelle version en revenant à T-1 (v3 >> -> v4 avec les attributs de v2). Mais quand on tente d'annuler le >> deuxième changeset (le premier chronologiquement), JOSM va avoir un >> conflit puisque la version de l'élément a évolué depuis (le changeset >> parle d'un v1 -> v2 qui n'est plus v2 mais v4 maintenant). >> Il faudrait en fait que le reverter prenne en charge des groupes de >> changesets au lieu de les faire un par un. >> >> Pour compléter; c'est plus compliqué que ça car un même changeset peut > contenir plusieurs versions successives d'un objet. > > Et lors d'une résolution de conflits entre deux changesets, ils vont > chacun créer des versions sur des objets séparés mais entremêlés (et assez > souvent pour les résoudre on est amené à modifier un même objet une seconde > fois dans le changeset). L'autre cas c'est le changeset resté ouvert pour > plusieurs modifs en séries. > > La granularité n'est donc pas le changeset mais uniquement objet par objet > avec des version séparées; réparties dans un nombre variable de changesets. > Noter aussi qu'il peut y avoir pluseurs changesets ouverts simultanément > par le même utilisateur et quel leurs modifs peuvent aussi s'entre mêler > (amais avec des conflits de versions possibles entre eux et à résoudre pour > chacun). > > Bref, faire un revert d'un ou plusieurs changesets c'est aussi compliqué! > Il faut lister toutes les versions de chaque objet modifié dans le(s) > changet(s) et repérer les versions initiales. Si on veut éviter de > compliquer avec des listes d'objets compliquées, on a intéret à faire les > reverts non pas en groupant selon leur changset d'origine mais selon leur > dépendances (objets liés : noeuds référencés par ways ou relations, ways et > relations référencées par relations) et travailler sur ces jeux assez > petits pour pouvoir traiter ces petits groupes séparément : ceci fait on > peut alors les déversionner étape par étape en parcourant les versions en > sens inverse > > _______________________________________________ > Talk-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-fr > >
_______________________________________________ Talk-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-fr
