Editing code locally after uploading the the file to Google Drive

[ClaudioZandonella]

I open this issue following a personal email, as I am sure it could be helpful for others as well.

The Problem

When I download a file from Google Docs where code chunks have been hidden, what versions of code chunks are restored in the local Rmd file. From the current file or old chunks from when the file was uploaded/updated to Google Drive?

Put another way, can we, after uploading/updating the file to Google Drive, make changes to code chunks only in our local Rmd file?

Currently, trackdown restores the old chunks from when the file was uploaded/updated to Google Drive. This means that any new change to the local copy of the file (code chunks or text) made after the document is uploaded to Google Drive will be lost when downloading that file from Google Drive.

This is one of the main limits of the package. We can not change simultaneously the code in the local file and the text in the Google Drive version of the file. The workflow has to be iterative:

• Upload the file to Google Drive to change the narrative text
• Accept changes and download locally to make changes to the code
• Upload again to Google Drive if new changes to the narrative text are required

This is a big limit.

Solutions

There is a possible solution but is a little bit laborious. The solution involves integrating the trackdown workflow into the git workflow.

Suppose we have our file and we want to use trackdown to collaborate with other colleagues on Google Drive. The workflow is:

1. We need to use git for version control. Suppose we are on the main branch
2. We Create a new branch (e.g., trackdown) and, from the new branch, we upload the file to Google Drive with trackdown.
3. Now we can go back to the main branch and keep working on the code (as well as text but is deprecated; see below). At the same time, colleagues can edit the document on Google Drive.
4. When the revision on Google Drive is finished, first we commit all the new changes on the local file in the main branch.
5. Next we checkout to the trackdown branch and we download the file from Google Drive. We commit the changes.
6. Summarizing, now in the main branch we have the local file with the new code (as well as text but is deprecated; see below) that we added locally. In the trackdown branch, instead, we have the file with the changes to the text from Google Drive and the OLD code.
7. We checkout to the main branch and we merge the trackdown branch into the main branch. In this way, the new narrative text is merged with the new code created locally.

Following this workflow, we can simultaneously on the code locally while collaborators are working on Google Drive. Actually, we can also modify the narrative text locally. However, in this case, it is likely we end up in some merge conflict (note that they can always occur).

This process is laborious. Note that if we need to upload again to Google Drive, first we need to merge the main branch into thetrackdown branch and then upload.

However, using git we are sure we will never lose parts accidentally. Moreover, git merge is very powerful in combining changes to different versions of the file (e.g., code and text). In this git is the best.

Alternative Solution

We can implement a possible alternative solution:

• trackdown checks current code chunks compared to those saved in the .trackdown/ directory before downloading the file from Google Drive.
• If the chunks are identical, restore the old chunks
• if the chunks are different, we can ask the user whether to restore old or new chunks

This process is much simpler but less secure. As long as we only change already existing files there are no problems.

However, if we add now code chunks they could brake the correspondence between tag names of placeholders and actual chunks. Restoring code, in this case, would be very difficult. Moreover, local changes to the narrative text will be always lost.

For these reasons, I would prefer to not implement this "easier" but not safe solution.

Conclusion

Instead of trying to achieve the same power of git, is better to use git. I much prefer the safer git solution, although it is quite complex for git beginners.

I leave the issue open because it could be useful to add the trackdown + git workflow to the documentation.

[krlmlr]

As a stop gap, can we record the Git SHA of the source file in some metadata of the Google doc? We can later use this to warn/abort if the file has changed in Git. Merging could also be left to the user.

We would do this only if the file is version-controlled, we could also warn/fail if it has uncommitted or even unpushed changes. During restore, we would use the SHA of the commit that has last changed the file.