À l'heure actuelle, borg diff affiche quelque chose comme ceci :
+27.4 kB -27.4 kB var/vmail/example.com/foobar/Auto/Steam und Co/dovecot-uidlist
+490.4 kB -489.3 kB var/vmail/example.com/foobar/Auto/Steam und Co/dovecot.index.cache
+29.6 kB -29.3 kB var/vmail/example.com/foobar/Auto/Steam und Co/dovecot.index.log
added 62.77 kB var/vmail/example.com/foobar/Auto/Steam und Co/new/1520542202.M174402P24533.turtle,S=62768,W=63599
+4.5 kB -4.5 kB var/vmail/example.com/foobar/maildirsize
Et c'est super. Sauf que ces informations de taille lisible par l'homme sont un peu difficiles à analyser pour une machine. Idéalement, il y aurait une option pour sortir des tailles lisibles par machine (c'est-à-dire juste les octets, sans aucun préfixe).
En parlant de préfixe : ces Ko correspondent-ils à 1 000 octets ou sont-ils des Ko à 1 024 octets ? Pendant ce temps-là, cela pourrait peut-être être clarifié aussi. Merci!
Avez-vous vérifié si nous avons un support de sortie json pour cela?
J'ai en effet vérifié le borg help diff
pour cela. La seule chose liée à JSON que j'ai trouvée est ceci:
--log-json Output one JSON object per log line instead of
formatted text.
Donc pas de chance là j'ai peur.
OK, si nous ne l'avons pas encore, ajouter une sortie json semble être une bonne idée.
Dans ce cas, je voudrais également demander d'inclure à la fois la taille non compressée et compressée de chaque modification. Pour autant que je puisse comprendre le code source Borg, la sortie actuelle se réfère à la taille non compressée.
Je propose d'ajouter une option --json-output
pour diff.
Et une sortie diff devrait être quelque chose comme ça :
{
added: [
{path: '/path/to/file', change: '27.4 kB'}
],
modified: [
{path: '/path/to/file', change: '+490.4 kB -489.3 kB'}
],
deleted: [
{path: '/path/to/file', change: 'directory'}
]
}
De cette façon, les utilisateurs auront un moyen facile d'analyser la sortie, car ils auront des groupes et des champs séparés.
Donc, je vais ajouter la fonction interne print_output_json
à do_diff
, qui produira la sortie comme ci-dessus à partir du générateur de différences.
Aussi pour le format non lisible par l'homme, nous pouvons ajouter une option --bytes
et afficher la taille du fichier sans unités. Je pense que ce serait bien d'avoir cette option et pour la sortie standard aussi.
Maintenant, la fonction diff utilise ItemDiff.__repr__()
remplacé qui à son tour utilise ItemDiff._content_string()
pour obtenir la représentation de la différence. Comme nous ne pouvons pas ajouter d'arguments à __repr__
À mon avis, ce serait g
ooo d'ajouter une fonction distincte et d'y mettre le contenu actuel __repr__
. __repr__
invoquera cette fonction pour obtenir la sortie standard. La fonction prendra un argument (par exemple in_bytes) et le transmettra
à Item.get_size()
. Franchement, je n'ai pas encore plongé dans Item.get_size()
, mais je pense que je peux obtenir la taille de l'élément en octets.
Des idées, des suggestions?
Je propose d'ajouter une option
--json-output
pour diff.
Cela devrait être --json
ou --json-lines
(en fonction de la sortie) pour la cohérence avec les autres commandes.
Et une sortie diff devrait être quelque chose comme ça :
De cette façon, les utilisateurs auront un moyen facile d'analyser la sortie
Non, cela semble plutôt difficile à analyser et à recombiner en quelque chose d'utile. La partie entière change
n'est pas meilleure que l'analyse de la sortie non-JSON existante, j'en ai peur.
Je suggérerais plutôt une entrée par chemin, ayant un champ type
pour fichier/répertoire/hardlink/softlink etc., une liste change
qui répertorie les types de changement, par exemple added
, deleted
, modified
(ou content
:thinking: ), owner
, mode
, etc., les tailles doivent être données en octets bien sûr, et probablement plutôt comme sizes { old: 12345, new: 12346}
Commentaire le plus utile
Cela devrait être
--json
ou--json-lines
(en fonction de la sortie) pour la cohérence avec les autres commandes.Non, cela semble plutôt difficile à analyser et à recombiner en quelque chose d'utile. La partie entière
change
n'est pas meilleure que l'analyse de la sortie non-JSON existante, j'en ai peur.Je suggérerais plutôt une entrée par chemin, ayant un champ
type
pour fichier/répertoire/hardlink/softlink etc., une listechange
qui répertorie les types de changement, par exempleadded
,deleted
,modified
(oucontent
:thinking: ),owner
,mode
, etc., les tailles doivent être données en octets bien sûr, et probablement plutôt commesizes { old: 12345, new: 12346}