Request: Keep git repositories after reboot

[Undftd]

First, thank you for developing this app. It's a great solution to working remotely without the lag of sshfs etc.

Is there a reason why the git repositories are removed when rebooting? It would be nice not having to download all the files each time I reboot my system.

I'm willing take a stab at implementing this functionality myself, any pointers would be appreciated.

[xenoscopic]

I'm actually rewriting xeno at the moment with this being one of the primary goals. When I wrote the current version, I really underestimated Git's robustness in terms of keeping sessions viable, but the fact of the matter is that Git is so stateless, that sessions can basically persist forever.

So anyway, I'm rewriting the project in C at the moment, mostly for portability and ease of installation, but the persistence of sessions is also a top priority, and in the new version they won't be ephemeral, they'll essentially stay forever until you stop them, even across reboots.

As far as patching the current version, it could in theory be done, but the sessions are so intertwined with the synchronization daemon that I think it would be quite difficult. I can give you a nasty hack to get around it, but it would involve some command line invocations that wouldn't save you any effort.

I'm working on the new version here:

https://github.com/havoc-io/xeno-c

It isn't functional yet, but I'm hoping to have parity with the existing version within a week or so. If I can get a free work day, I might be able to do it quicker.

So long story short, I don't plan on updating the current version to do this, and while it could be done, it'd be better to wait for the new version, which also has complete unit test coverage and will be far more robust. If you don't mind waiting, I'll leave this issue open and notify you once the new version is complete.

[Yeraze]

Wow, I'm surprised to hear you're converting it to C. I would think for a tool that primarily managed another external tool (git) some scripting language would be a better fit.

What made you decide to switch?

[xenoscopic]

Well, the Python 2.7+ requirement was a bit too restrictive, and Python in general can be a bit hard to setup, esp. if you're not an admin on the remote box. In theory I could target an earlier Python version, but I think Python is always a heavy-handed requirement for remote machines where a user may not have admin access.

I also want to build a simple tray icon app to compliment the command line, to give at-a-glance access to sync status and to have global key bindings to initiate a sync, and being able to share a code base will make things more robust (most likely it will be Cocoa or QT).

Finally, I think that a C version will actually be more portable than Python. I'm going for very strict C89/POSIX-2001 support, and libc will be the only requirement. I plan to have pre-compiled binaries against Linux Standard Base and other platforms, and a simple shell command or script to download binaries based on kernel name/architecture (similar to homebrew or Leiningen install). I also have a homebrew formula in the new version, and am hoping I can make the new version install xeno on the remote end if not present, which just wouldn't be possible with Python.

[Undftd]

It's very cool to hear this. I think you're developing a tool which will be indispensable for a lot of developers.

I look forward to the future releases. Keep up the great work!

[xenoscopic]

Okay, I have an update, though it's not quite what I expected.

After rethinking my response to @Yeraze, I realized that it is a bit silly to rewrite this in C. I still stand by my idea to drop the Python requirement and make it more portable, but C is not the answer, especially since the code reuse it would allow for a GUI tool would be minimal.

So instead, I put on my UNIX beard and rewrote the entire thing as a portable shell script. It's currently in the xeno-sh branch:

https://github.com/havoc-io/xeno/tree/xeno-sh

No more Python, it's all just a simple shell script:

https://raw.githubusercontent.com/havoc-io/xeno/xeno-sh/xeno

Download it and drop it in your path. I also simplified the synchronization mechanism a bit, and documented the synchronization flow a bit better.

Due to some of these simplifications (which are for the better), this new version is no longer compatible with the Python version. I am going to use the new version some more over the next week, and if there are no show stoppers, I'll likely go ahead and merge the new version as master.

Some of the new features:

• Sessions now persist indefinitely (until manually stopped)
• Session stopping should be more robust in terms of resource cleanup
• Should work with tmux/screen
• Session ids are nicer now
• Daemon is shared amongst all sessions
• The xeno command locks its working directory to ensure the daemon and/or multiple xeno commands don't clobber each other
• Generally simpler model, faster

I have a pull request open (https://github.com/havoc-io/xeno/pull/9). If you feel like trying this new version as well and notifying me of any issues in that PR, that'd be great. This new version is still very beta, but it has worked in testing so far, and for the most part it is shelling out the same Git commands as the current version.

I'll hopefully expand the Travis CI testing on that branch as well beyond basic syntax checking. The infrastructure is in place, I just need to write the tests in scripts/ci-test-xeno.sh.

[xenoscopic]

I've done a lot of testing of the new shell version. It now has better test coverage than the existing version, and unless there are any issues that I come across, I'll probably merge pull request #9 pretty soon. In any case, the new version is probably more robust. If you have a chance to test it, it would be good to get some feedback. The coolest part of the new version is that it no longer needs to be installed on both ends, it will just copy itself over. Before you use it though, I would uninstall the Python version on both ends.

[Undftd]

Nice! I'll let you know if I run into any issues.