Importați istoricul de revizii pentru documente Google Docs într-un depozit Git?

Aș dori să vizualizăm istoricul revizuirilor unui document Google Docs utilizând instrumente mai flexibile, cum ar fi Git, și, eventual, să migrăm un anumit conținut din Google Docs într-un proiect Git.

Documentele Google au un API cu acces la istoricul reviziilor, deci ar trebui să fie posibilă, pentru oricare varietate de formate de export pe care le suportă. Totuși, am observat că au existat câteva probleme API cu istoricul reviziilor , ceea ce înseamnă că lista contribuitorilor la fiecare revizuire poate să nu fie completă, deși intenționează să stabilească că:

Uneori există mai mult de un editor (pentru o anumită revizuire). Cu toate acestea, API-ul îmi dă întotdeauna un editor pe revizie.

Există vreun cod sau sfaturi în acest sens? Exportul către un alt sistem de control al versiunilor precum bzr, Mercurial, SVN sau CVS ar fi, de asemenea, de interes.

Acest lucru este legat de întrebarea privind depășirea stivei Controlul versiunii cu cele mai bune practici Google Docs? a>, care a fost închis ca pe o temă acolo.

13
adăugat editat
Vizualizări: 5

2 răspunsuri

Lars Kellog-Stedman created a great little python app called gitdriver which I found on this answer at StackOverflow. It does what you're looking for. It authenticates to Google with OAuth and pulls down all the revisions of a document, committing them to a git repository.

Cu aceasta, puteți să preluați o copie versială a documentului Google Doc și să lucrați cu acesta utilizând instrumentele tradiționale de tip git.

9
adăugat

Revisionator este un alt sistem de documentație online (cum ar fi Google Docs), dar cu control revizie integrat. Se aseamănă cu instrumente mai flexibile, cum ar fi git, în sensul că are suport pentru diffing, branching și 3-way merging (dar cu un front gui web).

IMHO, istoricul reviziilor Google Docs nu ar fi potrivit pentru a importa oricum un proiect git. Problema este că nu există nicio noțiune de copie de lucru. Pe măsură ce oamenii fac modificări, ele sunt imediat reflectate în document și anexate istoricului reviziilor. Vizionarea istoricului se dovedește a fi o mizerie nesănătoasă.

Revizorul (ca bzr, mercurial, git, etc) are o noțiune de copie de lucru. Prin urmare, puteți lucra la o schimbare până când este gata să fie eliberată. Când este lansat, apare ca o revizuire în istoricul revizuirilor (mult mai ușor de citit).

4
adăugat
Sunt de acord că este o provocare să facem față unui număr mare de revizuiri de acest gen, dar ar părea cel puțin posibil să le împachetezi în pachete atunci când există o pauză în editare sau o schimbare în cine fac modificări.
adăugat autor Rajat Saxena, sursa
Poate, dar nu și dacă diferiți oameni editează documentul în același timp. Și chiar dacă le îmbraci în funcție de timp, nu există nicio garanție că ciorchinii reprezintă o singură modificare logică a documentului. IE, lucrez la o revizuire, mă retrag. Întoarce-te mai târziu și rezolvi. Oamenii văd două ciorchini de modificări în istoricul reviziilor (și documentul rupt între ele).
adăugat autor jpalmucci, sursa