Versioning only works when a remote host modifies a file?

[toomanydata]

I noticed that versioned files only appear on the other hosts when something is changed locally. Why is that the case? Why aren't versioned and deleted files stored locally as well as remotely in the .SyncArchive folder? It would be nice to have a full 30 day history on all hosts. Is there any way to achieve that with the software as-is?

[leexgx]

if you edit the file locally the changes are propagated to remote clients, only remote clients will backup to the .SyncArchive folder (the local BTsync would have had to already had an copy of the file before it was locked Locked read only or RW by the program that is editing it)

​you need to use dropbox or other cloud based service if you wish to have full versioning (moved all my important stuff back to dropbox at the moment as bit hit or miss at the moment the way BTsync handles files)

[toomanydata]

(the local BTsync would have had to already had an copy of the file before it was locked Locked read only or RW by the program that is editing it)

You could always request the previous revision from the remote peer (from their .SyncArchive) so that local edits need not 'be predicted' in the scenario you posed. The file is out there and available and the platform is built around collective sharing of info. It certainly seems feasible as a feature.

​you need to use dropbox or other cloud based service if you wish to have full versioning

You may be able to get away with using an SVN repository inside the shared folder but I imagine that will cause a lot of conflicts.

[hitchhiker]

This feature needs to be implemented as fully as the pack-rat feature on Dropbox - it's something (i'm guessing) a lot of people use to guarantee the availability and safety of important repos. I was excited to see it available at all, it's unfortunate that it's so 'sparse' an implementation.

I currently use 'timeline' software (on win) on a second node to make constant backups of the repo.

[syncert]

What would be the problem if you also sync the folder with the versioned files? Then the complete history would be the same on all synced devices.

[goli]

Hey there.

Btsync is no file system driver. Never was, and most likely never will be. It just works ontop of a given file system and deals with local files.

So, what's the process of keeping a local change history if you are not a file system yourselfe?

I have a local file. Then I open this file with, say, excel, and hit the "save" button. Excel persists local changes, the file gets changed.

Now, how should btsync know about the previous version of the file as soon as the current one is in place?

Excel doesn't tell btsync "there's something going on with the file, I'll write in 500ms!" which would enable btsync to copy the last version to its history.

There are two options:

1. Btsync keeps a static copy of the current versions of each and every file. This is the only way to have a standalone application be aware of the history. And that's pretty much what e.g. GIT does: Keeping its own ".git" directory that, dealing with binary files, usually takes the amount of storage space necessary for the source files in addition.
   This can be seen as a local backup.
   So this would double the necessary disk space instantly even if not a single file has ever been modified. Just twice the disk space needed for keeping one untouched copy of each file.
   
2. Btsync could ask other nodes what's their current version. That's what currently is going to happen just to upload the modified file. Btsync could, prior to copying the modified file to other nodes, fetch the last version from the remote nodes.
   To sum this up: Btsync could synchronize the history, too.
   

The first thig is clearly awfull. There's 20GB in my music folder. Most of the stuff never changes. I activate history just to make sure that no wrong timed node trashes the library. This currently creates ~30MB of history files because of modified ID3 tags. Using a local history based on a untouched backup folder here would instantly increase the disk space from 20GB to 40GB.

The second thing, on the first sight, is awfull too. It creates unnecessary traffic. But on the second side, this would only double the traffic. Based on the fact that btsync uses block based synchronization and usually doesn't copy the whole file, I guess I could live with that, if I would want local history.

Compared to Dropbox: There's no local history of dropbox files here, is it? The only history you have is the remote one. The reason btsync uses a local history isn't to have a local history. It's because in a serverless environment the only storage you have is the local one.

But: To be honest, if I would want local history stuff, I would use a dedicated tool for that.

There's no reason for btsync to do this, too. The remote history is a nice thing because you never know which of your participants manipulates your files. So the btsync remote history just keeps track of anwanted changes of remote nodes that are not under your control but under the control of other people.

What about using GIT? I think there are GUI or GUI-less tools that do local versioning. I'm thinking of Sparkleshare, currently. I don't know how far they have come recently, but that would be my best bet.

Regards,

Stephan.

[syncert]

Hi Stephan,

Thank you for your kind and elaborate explanation. I'm a programmer myself, so I understand why btsync works this way. The reason I asked about the second option you mention is that btsync advertises that it has versioning but the implementation can only be understood by computer-people. For a regular user the behaviour is very strange because the version is made on other machines than the one were the file is changed. So it would be more natural to either not do versioning at all or synchronise the versions on the different machines. In this last way the user does not have to search for an old version and you would have something that is even better than DropBox because it has the versions locally.

I agree that this is only useful for casual users who make a mistake and would like an old version. For real versioning I also use a real system like git or subversion.

Kind regards,

Ruud

[goli]

Hey Ruud.

If you would like to have synchronized versioning folders, you should bring this topic to the wishlist thread. Imho it's not a bug but a missing feature. So the wishlist is the right place for this.

I think as soon as (or ... "if", since there is no public roadmap) there is partial and blockwise synchronization that takes other files than the current one into accout ("look aside synchronization" feature, I would call it, something like that has been requested in the wishlist thread) it's just tiny step ahea to synchronizing history, too, because the most of the files content should be already in place in other files.

So: Would you mind bring this to the wishlist thread?

Regards,

Stephan.

[syncert]

Hi Stephan,

I have added it to the wishlist. I do not think it is a bug, only a feature that can be implemented better so that non-programmers can understand it more easily. Again, thanks for your replies.

Regards,

Ruud