this is great too hear! I really love to have distributed version control included in the thoughts, I.e. git or mercurial.
an idea would be to have one repository holding one subrepository per page. it stores (at least part of) the history. an edit is then committed on top of it whole edits coming from the central site are a natural branch when you next time synchronize.
to edit the page (which is a text file on disk) anything can be used with varying level of comfort.
an example for such an implementation where an external unique reference is stored is when git or mercurial are used as clients to subversion. and that you address this unique reference as well is hularious :)
rupert. On Feb 17, 2012 12:58 AM, "Adam Wight" spam@ludd.net wrote:
rupert.thurner@gmail.com:
this is great too hear! I really love to have distributed version control included in the thoughts, I.e. git or mercurial.
an idea would be to have one repository holding one subrepository per page. it stores (at least part of) the history. an edit is then committed on top of it whole edits coming from the central site are a natural branch when you next time synchronize.
to edit the page (which is a text file on disk) anything can be used with varying level of comfort.
an example for such an implementation where an external unique reference is stored is when git or mercurial are used as clients to subversion. and that you address this unique reference as well is hularious :)
rupert.
The idea of having one repository per page is great! It totally gets around the scaling problems with large repos.
Hmm, in the "tiddlywiki" case, if pages on disk have the permission to self-modify, does that mean we could store each article in its own text file? Yes iff the html5 FileSystem API exists... otherwise, the javascript security model probably won't cooperate.
-Adam
rupert.thurner@gmail.com:
this is great too hear! I really love to have distributed version control included in the thoughts, I.e. git or mercurial.
an idea would be to have one repository holding one subrepository per page. it stores (at least part of) the history. an edit is then committed on top of it whole edits coming from the central site are a natural branch when you next time synchronize.
to edit the page (which is a text file on disk) anything can be used with varying level of comfort.
an example for such an implementation where an external unique reference is stored is when git or mercurial are used as clients to subversion. and that you address this unique reference as well is hularious :)
rupert.
The idea of having one repository per page is great! It totally gets around the scaling problems with large repos.
Hmm, in the "tiddlywiki" case, if pages on disk have the permission to self-modify, does that mean we could store each article in its own text file? Yes iff the html5 FileSystem API exists... otherwise, the javascript security model probably won't cooperate.
-Adam