Re: Python script for automatic synchronization based on inotify
Am Freitag, 18. März 2011, 22:59:07 schrieb Dieter Plaetinck: > I found sparkleshare very disappointing. I spent more time reporting bugs > for all kinds of stupid things then actually using the software.. I got it to > sync 1 file then it stopped and I gave up. > https://github.com/hbons/SparkleShare/issues/79 > https://github.com/hbons/SparkleShare/issues/80 > https://github.com/hbons/SparkleShare/issues/81 > https://github.com/hbons/SparkleShare/issues/84 On my initial tries, I also ran into a few issues with Sparkleshare, but I haven't given it too much time so far. > Your program passed my initial testing, the code seems more robust and the > design is more sane. Nice to hear. > Also, I'll take 605 lines of python over 9k lines of mono any day. That was my main reason for taking Python: rapid prototyping with mature libraries (pyinotify just rocks, e.g. compared to the JNI inotify wrapper). > I have already one bugfix for you: > http://gitorious.org/~dieterbe/dvcs-autosync/dieterbes-dvcs-autosync/commit/f510cd5975244cbb0d0558b8929baf68bfa59425 Thanks - I will try to merge this tonight/tomorrow, as soon as I have wrapped my head around the gitorious merge request interface. > I hope to contribute more later on. Preferably once you have a clean git > history. > I will try to start relying on this to synchronize my notes, and then some > other files.. Excellent. I am open to many changes/improvements in this little project. > 2) What's the very minimum a user should do (other then installing the > software and configuring ~/.autosync) ? > What I did: (in this case, in ~/.autosync path is set to ~/autosync) > $ ssh server git init --bare test.git > $ cd ~/autosync && git clone server:test.git That's basically it. Then you start the script and it should be working for monitoring local changes and automatically committing them. For synchronization with other instances, you will also need to configure an XMPP account to use for this purpose. > Note if you do this, server:test.git won't actually have a master branch yet. > So when i touch ~/autosync/test, I get this: > > No refs in common and none specified; doing nothing. > Perhaps you should specify a branch such as 'master'. > fatal: The remote end hung up unexpectedly > error: failed to push some refs to 'server:autosync.git' > > workaround is typing `git push origin master` once. after that it works fine. You're right. I've never actually tried it on a completely empty repository. We should either document this in README (the setup process) or make the script realize when there is no master branch and do a "git push origin master" in this case. I will need to dig into the git remote command a bit more to see what the best option is here (I don't like parsing the output if I can avoid it). best regards, Rene signature.asc Description: This is a digitally signed message part. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Python script for automatic synchronization based on inotify
On Sun, 20 Mar 2011 08:31:39 +0100 René Mayrhofer wrote: > Am Freitag, 18. März 2011, 22:59:07 schrieb Dieter Plaetinck: > > Note if you do this, server:test.git won't actually have a master branch > > yet. > > So when i touch ~/autosync/test, I get this: > > > > No refs in common and none specified; doing nothing. > > Perhaps you should specify a branch such as 'master'. > > fatal: The remote end hung up unexpectedly > > error: failed to push some refs to 'server:autosync.git' > > > > workaround is typing `git push origin master` once. after that it works > > fine. > > You're right. I've never actually tried it on a completely empty repository. > We should either document this in README (the setup process) or make the > script realize when there is no master branch and do a "git push origin > master" in this case. I will need to dig into the git remote command a bit > more to see what the best option is here (I don't like parsing the output if > I can avoid it). > > best regards, > Rene I also thought of some options. What about always explicitly pushing the current branch? unfortunately there is nothing like `git push origin --currentbranch`, so we would need to do ask git "what is the current branch", and then `git push origin $branchname`, but that involves an extra process; we could try to cache the result but that gets ugly quickly (you need to know when to invalidate the cache, i.e. when the user creates a new branch). on the other hand, something like this would transparently allow the user to work with multiple branches; as far as i see there is currently no notion of the branch in autosync.py (i.e. "master" is always assumed), if we always do `git push master` we can fix the problem at hand (but then the user is restricted to the master branch, if he creates a new branch and we do a push of master, his new branch won't be pushed), if we do `git push $currentbranch` and also have a notion of the involved branch in the jabber messages, then the user could transparently use multiple branches. Either way I don't think we should query the remote for "what do you have", frankly we shouldn't care. we only care about pushing (explicitly enough) the thing that we need to push. If you only want to support a master branch, hardcoding `git push origin master` is a good choice, but I don't like restricting ourselves like that. We can also say in the readme "every time you create a new branch, push it manually once", from then on, we can just `git push origin` and it will do the right thing. it involves a tiny bit of manual work, but maybe this is the most sensible. Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: Python script for automatic synchronization based on inotify
On Sun, 20 Mar 2011 12:26:36 +0100 Dieter Plaetinck wrote: > On Sun, 20 Mar 2011 08:31:39 +0100 > René Mayrhofer wrote: > > > Am Freitag, 18. März 2011, 22:59:07 schrieb Dieter Plaetinck: > > > Note if you do this, server:test.git won't actually have a master branch > > > yet. > > > So when i touch ~/autosync/test, I get this: > > > > > > No refs in common and none specified; doing nothing. > > > Perhaps you should specify a branch such as 'master'. > > > fatal: The remote end hung up unexpectedly > > > error: failed to push some refs to 'server:autosync.git' > > > > > > workaround is typing `git push origin master` once. after that it works > > > fine. > > > > You're right. I've never actually tried it on a completely empty > > repository. We should either document this in README (the setup process) or > > make the script realize when there is no master branch and do a "git push > > origin master" in this case. I will need to dig into the git remote command > > a bit more to see what the best option is here (I don't like parsing the > > output if I can avoid it). > > > > best regards, > > Rene > > I also thought of some options. > What about always explicitly pushing the current branch? unfortunately there > is nothing like `git push origin --currentbranch`, so we would need to do ask > git "what is the current branch", and then `git push origin $branchname`, but > that involves an extra process; we could try to cache the result but that > gets ugly quickly (you need to know when to invalidate the cache, i.e. when > the user creates a new branch). on the other hand, something like this would > transparently allow the user to work with multiple branches; as far as i see > there is currently no notion of the branch in autosync.py (i.e. "master" is > always assumed), if we always do `git push master` we can fix the problem at > hand (but then the user is restricted to the master branch, if he creates a > new branch and we do a push of master, his new branch won't be pushed), if we > do `git push $currentbranch` and also have a notion of the involved branch in > the jabber messages, then the user could transparently use multiple branches. > Either way I don't think we should query the remote for "what do you have", > frankly we shouldn't care. we only care about pushing (explicitly enough) > the thing that we need to push. > > If you only want to support a master branch, hardcoding `git push origin > master` is a good choice, but I don't like restricting ourselves like that. > We can also say in the readme "every time you create a new branch, push it > manually once", from then on, we can just `git push origin` and it will do > the right thing. it involves a tiny bit of manual work, but maybe this is > the most sensible. oh, one more thing. you can query the current branch in a pure-python way, by reading .git/HEAD that way the user doesn't need to bother about pushing the branch the first time, and it's probably not a noticeable performance overhead to look at the current branch every time you want to commit/push. there are some python libraries for git as well, by depending on them, we could use such a library to abstract some of these things for us; and they might come in handy for other things in the future as well (like checking ignore rules?) Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
