Bisync Bugs and Feature Requests

[ncw (Nick Craig-Wood)]

@nielash

I'm happy to submit a PR for the handful of small fixes I made in my fork, if that's helpful. I'm not sure I can commit to doing everything on my long wishlist, but I could at least contribute a few improvements that should go a long way. Also, I'm relatively new to Go, so I'd definitely want you to check my work and tell me if there are better ways to do certain things.

I can also suggest some documentation edits to turn some of these "bugs" into "known issues".

Yes PRs to fix bugs and add documentation would be most appreciated.

bisync has an extensive set of tests so if you find a bug you'd like to fix, if possible create a new test case first that fails and then fix that testcase.

I would review all code submissions as a matter of course, and I've mentored many new Go contributors

My problem is that rclone is a big project now. There are over 250k lines of source! This is way too much to fit in my head which is why I haven't engaged with the bisync source very much (despite being only 3k lines) very much. I left that to ivandeex who did a great job and is a very talented developer. Unfortunately due to the situation in Russia at the moment he can't contribute to rclone any more, and in fact haven't heard anything from him for over a year

So I'm really looking for help with bisync. It needs someone to really understand the nuances of the source code. Clearly you two @nielash and @jwink3101 are my best bet so far and I'l love to get you both involved in contributing code.

@jwink3101

I am honored. Here is the issue. Programming for me is nearly all hobby. On the rare occasions my wife takes the kids out of town, I programmed 18+ hrs a day (meet dfb . Not yet posted here but early beta). But it is all Python. I was able to use Python for work for a long time (I did my PhD with Matlab but got tired of it so I moved to Python when I started working). Even for work, I do little programming work now.

I know exactly where you are coming from. I started the rclone project at a time when I was doing 100% management at work as a busy CTO and I needed a bit of relief from that by writing some code. Now I do rclone more or less full time.

@jwink3101

So to learn golang enough to even start to help would be tough. I may be able to do a (vacation from work) day of live assist in the algorithm and the nuance but to actually be set free with code would be tough.

I hear you. I think you'll find Go easy to learn though. If you've ever programmed C it will be immediately familiar (it's like C without the hard parts and the type declarations backwards). Any experience with a statically typed language will help. Even if Python is your first and only language I don't think you'll have a problem learning it. The main thing you'll find missing in Go is inheritance and the main thing you'll have to learn is error handling! Otherwise Go really is quite a simple language. I recommend all experienced coders start from the Go tour

@jwink3101

If we were to do that, I suspect we'd create an amalgamation of bisync and syncrclone since the latter works on a config file. It could be flag-based I guess. It would have to deal with how to handle new combinations of remotes. We'd likely want to borrow that and the where-to-store the DB from bisync.

I'm open to suggestions. We could evolve bisync. In the short term that's probably the best thing to do.

We could also start afresh with bisync2 or maybe even port syncrclone into Go.

As far as rclone users are concerned, bisync is still in beta. As long as we provide a reasonable migration path (ie run these commands to migrate from bisync to bisync2) then I don't mind a fresh approach.

I have no particular feelings on flag based vs config file - whatever is easiest for the user is my guiding principle.

The DB part of bisync is based on a very robust key value store that ivandeex wrote a little wrapper around to make multi-process. I think that is a very useful bit of technology and if a DB is needed, that would certainly be my preference.

@jwink3101

If you do want to try to pair-program "bisync2", I am willing to take a vacation day from work but we have to plan it out. I am in Albuquerque, New Mexico, USA. We'd have to make the times work.

That is a generous offer. I'm based in the UK so currently on UTC+1 so that is 7 hours difference.

I suggest what we do is carry on generating ideas for the moment and see if we can come up with a plan!