Since I wanted to synchronize my Pythonista files with my project on GitHub I installed the iOS app "working copy" and use my little tool "gitsynchista" to move files back and forth between the local Pythonista directory tree and the WebDav server offered by "working copy".
See https://github.com/marcus67/gitsynchista for a (still very short) ReadMe and a downloadable self-extracting Python script.
Have fun!
If I want this script to do all the syncs into a specific Pythonista subdirectory, what do I have to change?
The general approach is to synch one directory tree on the WebDav server with one directory tree on Pythonista. So for example if your local directory is localdir and the remote directory on the WebDav server is /remotedir you would have one configuration file
[repository]
name = whatever logical name you prefer
local_path = ../localdir
remote_path = /remotedir
Of course, you will still have to set the [webdav] configuration items appropriately.
Thanks. I have found the conf file in /etc. I would recommend placing that information in the readme file as well.
I have also found the WebDav settings in Working Copy, and copied the credentials to the configuration file. But all I am getting is 401 Unauthorized. Possibly related to that I do not know what the remote directory should be. Is it just the local repository name in Working Copy?
Mikael, I would suggest you set the access scope of "working copy" to localhost and try to access the repository without authentication. I remember that I had trouble when I started using the easywebdav library and was quite frustated that it did not work for me in the beginning. I guess I disabled authentication at some point along the way and so far haven't tried to reactivate it. If deactivating authentication works for you maybe we should send a note to the maintainer of the library and ask for advice.
Going local and removing username/password helped, in that I did not get an error and got loads of log output. Unfortunately no files appeared in the target directory.
Please find the log output here. Is it obvious to you what went wrong?
Thanks.
Browsing through the log file I cannot see an obvious errors. You seem to have a directory /MarkdownView/.git on the WebDav server which is not in your local file system yet. So all files in that directory tree end up in the the list "Remote new files". However, not a single file is transferred. My suspicion is that this is somehow related to the fact that you try to synchronize a "." (dot) directory. In my script there is a default ignore pattern for dot-files which is apparently in your case not activated since I made a coding error: the default ignore pattern is only added to the list if there is a local ignore file defined which is does seem to be the case in your configuration.
I introduced this ignore pattern since there's currently a limitation in the "working copy" app when it comes to dot files: they cannot be transferred. However, as I can see in your example this does not seem to apply to dot directories, so my pattern is too general. I will try if I can successfully transfer a dot directory and make fixes for that if required.
The real questions, however, is: Why would you want to transfer anything in your .git sub directory? My understanding is that normally this directory only contains technical control files denoting the state of your git project which are better left alone. So far I have used my script to synchronize with three git repositories using "working copy" and in none of them the directory '.git' was visible in the WebDav server at all which is exactly what I would expect from a git client: keeping the scary details away from me. How exactly did you bring all these files into the "working copy" app? Did you do anything else besides "cloning" the git project?
I did not mean to request a /MarkdownView/.git directory.
In the configuration file I have the following:
name = Markdown
local_path = ../git
remote_path = /MarkdownView
... where the local git directory is just something I set up to isolate any sync results from the rest of my local directory tree.
Could you give me your GitHub repository name so that I could clone it and try it myself?
Sure, it is the MarkdownView repository: mikaelho / pythonista-markdownview
Take a look at my clone https://github.com/marcus67/pythonista-markdownview. It contains a working configuration file in the etc subdirectory. You may want to change the name of the local directory. The name of remote directory is basically set by the cloning step in "working copy" since the app uses the project name in GitHub as base directory.
Apparently, your version of "working copy" returned the dot directory ".git" before my version did (it does now). So, at first I could not reproduce the error. The new version of my app is able to handle the .git subdirectory. It is simply suppressed automatically.
Hmm I'm unable to get it to work with my working copy. Idk why it's still getting its access denied. Should probably import from easywebdav instead of forcing the user to slap the client file outside if the folder.
There's an issue with authentification in the easywebdav module. If you are using the tool locally, try to switch the WebDav server to localhost and remove user and password both in working copy and in gitsynchista. Then, try again.
Fantastic, it works. Now I can keep all of my scripts backed up on github.
@miwagner1 : Glad you like it. By the way: I'm working on a simple GUI for pythonista which lets you pick the application to sync and see a preview of which files will be synched. I'm still having a little trouble with the x-url-callbacks of Working Copy but, in general, it works. I'll write a post when I think that it can be used by others.
Works now for me as well.
Although I have problems with:
@mikael I am the developer of Working Copy.
I will be looking at this delay you experience when doing x-callback-url commands. I have heard about this before and it should not be that way.
When Working Copy is put in the background it will only be allowed to run for a little while before being put to sleep by iOS and then the WebDAV server shuts down as well. Could this be what you experience?
@mikael: Until I've found out what I'm doing wrong with the x-url-callbacks simply deactivate the automatic webdav server wakeup by getting the latest version of the tool and inserting
[repository]
working_copy_wakeup = False
into your configuration file.
@palmin : It was me who wrote you mail about the blocking x-url-callbacks about two days ago. :-) If I have time tonight I will try with the latest versions of both Pythonista and Working Copy and send you a more detailed description of the phenomenon.
@marcus67 Ah yes, I see your email but have not yet had time to investigate.
As soon as I know why it happens, the fix is probably not far away.
You will hear from me.
I have tried with working_copy_wakeup = False, but see no difference in the behavior.
I am also aware that the WebDav server turns off after a while, but here it is consistently and immediately off every time I start Marcus' script, even if I had just turned it on.
@mikael : Are using the current version (= last night) of gitsynchista?
@marcus67: Just got the latest version, same behavior persists with wake up parameter set to False: empty repository page shown, WebDav turned off.
Working Copy version is 2.5.
@mikael Very strange. I will look into this. Are you using gitsynchista with (console mode) or without parameter (=GUI mode)?
@mikael I've just tried the console and the GUI version. They both worked for me. Still, to be sure I've updated the self-extracting archive. Please, do as follows: install the latest archive, go to log.py and set the debugging level to DEBUG. Start gitsynchista with your configuration file as parameter. If the trouble persists send the logging output to marcus.rickert@web.de. Thanks!
@miwagner1 @mikael The problem with authentication has been fixed. The error was caused by the fact that 'working copy' uses HTTPDigestAuth whereas the default mode of easywebdav is HTTPBasicAuth. If you want to try it you will have to get the latest deployment package of gitsynchista and the latest of copy of easywebdav from my clone at GitHub.
However, if you only work locally, why bother? :-)
@palmin I just tries to reproduce the error which so far always occured upon the second call of the x-url-callback. Fortunately, I was not able to reproduce it which is that the server was also started by the second call. However, during both the first and the second call it takes 'working copy' about 10 seconds to return to Pythonista.
This is the call issued: working-copy://x-callback-url/webdav/?cmd=start&key=[KEYREPLACED]&x-success=pythonista%3A%2F%2Fgitsynchista%2Fgitsynchista%3Faction%3Drun%26argv%3DIGNORE_WAKEUP'