Versioning Local File

[ClaudioZandonella]

A current limit of the trackdown workflow is that two copies of the same file exist: one local and the other online in Google Drive. The workflow implies sequential steps where the file is uploaded to Google Drive for changes to the prose and downloaded locally for changes on the code. Changes can not be made simultaneously on the code locally and on the prose on Google Drive as the two document versions can not be merged together but only overwritten, losing one of the two versions.

In this issue, we can discuss solutions to overcome this limit. Here are three possible directions:

• @filippogambarota suggested the following procedure.

  • Currently, code chunks of the local file are extracted from the document and saved locally in the hidden folder .trackdown only if argument hide_code = TRUE. We could extract and save code chunks every time the file is uploaded/updated to Google Drive. This allows us to have a saved version of the original code.
  • After editing on Google Docs, when the document is downloaded locally we could first check if the code in the local version of the document has been modified (changes in the old chunks or new chunks been added) compared to the original code previously saved in .trackdown.
  • If the code has been modified we can ask the user whether to restore the code chunks using the original code saved at the time of upload/update or using the new code present in the current local version.

• @januz suggested having build-in versioning that saves the local file (with date-time stamp) to a hidden folder so that one could at least manually recover local changes that weren’t represented in the online version. One could also save a version of the file every time it is uploaded to GoogleDrive and use that to see whether there have been local changes. Moreover, the option to diff and merge changes should not be restricted to code chunks but also use for the prose parts as well.

• For versioning of the file and saving copies of the document, I would encourage users to rely on Git this is probably the best solution. Ideally, the user would follow the following workflow:

  • make a commit before uploading/updating the document to Google Drive that can be used as a reference point if anything goes wrong
  • create a new branch (e..g, revision) and upload/updat the document to Google Drive
  • than she/he can keep working locally on the master brach to the code or also to the prose and commit when changes are made
  • once editing/revision in Google Docs is terminated user have to switch to the branch revision and download the document
  • now there are two versions of the document, the local copy in the masterbrach with some changes and the online edited version in the review branch.
  • using git merge review -m "..." from the master branch it is possible to merge the two version using the power of git
  • I realize that this process requires some programming skill to do everything. Moreover, there are really high chances of merging conflicts so the user has to solve conflicts by hand. Git does not show differences in an intuitive way (this is one of the advantages of trackdown) but Git is very robust. Probably this workflow works better for the code chuncks. Making changes to the prose will create inevitably many conflicts if changes are done also online.

Overall I would summarize that git is highly recommended (if not mandatory) for versioning but we could still include some processes to facilitate for example the margin of code chunks as suggested by @filippogambarota