I saw in the mockup that you get the current version which is the latest uploaded/edited, what about dev versions or beta, alpha etc?
ccan we have a current stable and a dev branch in one file history, when you ask the file you get the stable website/file and when you add v=dev or ver=beta you get the latest beta? or this should and is a thing that developers should do in another address and beta dev are not supported in the same stable address?
@maidsafe can we have an answer?
I’m presuming you are talking about the Perpetual Web Browser mock ups here… What you see in the mock up represents the way the appendable data works, and how versions history for individual files/pages is represented, i.e an HTML file has an edit history, a stacked list of versions, each appended on top of the last. There are no branches.
A version control system could certainly be created on top of SAFE, with some pretty amazing possibilities, and this could be used as a way of developing and maintaining a site. But what an end user will see in the browser is effectively a history of ‘production’ releases to individual pages and assets.
So branches should be different addresses where when one beta is stable it gets copied and pasted to the address that is the production website?
It might be more like just a change in mapping of a Public Name, as the XOR addresses of the content would remain constant when a file went from dev > stable. Maybe you could achieve this manually with Sub Names: safe://dev.site > safe://beta.site > safe://site.
However, every commit you make public, will be perpetually available on the network, and become part of the site history. That may, or may not, be what you want. Perhaps a better workflow would be a dev site be worked on as Private AppendOnly data, or Private Mutable data, and the when it’s ready to be released as stable, it is added as a version of the live site.