> Do you mean that you completely skipped version control? Since DdocLab source docs are PouchDB/CouchDB/Barrel docs, and have revisions, actually, there exist version control. UI of public version does not give you control over revisions, but it‘s a matter of time. I personally use aside mechanics for it, and this mechanics will be eventually merged inside Ddoc Lab. Task isn‘t so easy, cause we need to be protected from accidental DB compaction.
TWIMC, current roadmap for Ddoc Lab is: 1. Create good manual – too many features are now hidden under small UI buttons/checkboxes. 2. Add TAR as a special attach type, able to combine several files into it – to allow `npm install http://localhost:5984/db/_design/ddoc/npmPackage.tar` scenario 3. Add jsondiff component to allow source revisions comparison 4. Add github support (first one way, then two way) 5. Add Erlang editor (to allow Erlang views etc) ermouth ermouth 2015-11-05 13:48 GMT+03:00 Aurélien Bénel <[email protected]>: > > the advandage I see (…) is that we skipped Github fir ddocs because it > actually works well in a team too. > > Do you mean that you completely skipped version control? As for us, we > couldn’t do that. > > Don’t take it personally, Ddoc.me is really interesting (and I think I > will use it to teach CouchDB). But there is still a need for a command line > tool for teams that require traceability, visibility or testability. > > > Regards, > > Aurélien
