Welcome!
This is the community forum for my apps Pythonista and Editorial.
For individual support questions, you can also send an email. If you have a very short question or just want to say hello — I'm @olemoritz on Twitter.
[Share Code] Tool to synchronize with a WebDav server
-
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 theetc
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:
- Working Copy always displaying an empty repositories list when I run the script, takes a long moment and is of no apparent value to me. Plus always turns the WebDav server off so that I have to go and turn it on a second time. Probably related to the callbacks you are working on.
- I am not able to provide an argument to the script (Pythonista is not saving the argument for some reason).
-
@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.