Aurélien, skipping Gitub and version tracking is in a context where you have junior developer doing small web sites as modifications of some template sites and another developer maintaining css on several similar small sites. If a third person is needed for content updates, complicated updates are easily thrown from the content manger (using Inliner, a Ddoc Lab companion application) to the developer and back easily.
One use case is event sites with lots of content changes and paralell needs to reformat and tweek the presentations in terms of templates, css and some couch stuff. To think of the site as a new version with staging sites worked out very well. Site versions "Live", "tomorrow" and "nextweek" then become the versions I want to control. Instead of tracing the changes of single lines of code the version control is about entire sites that change from week to week and in the most hectic periods from day to day. Far from all of the smart things you can do with Ddoc Lab has been documented yet, but I think it is very promising. Your idea to use it to teach CouchDB is where we see the same, I think. it's very illustrative, but the reason I am such a fan is that I see the possibility of turning a junior developer into a productive site manager much more quickly than on any other tool/platform. With a few tweeks to the application server functionality of CouchDB this will outperform LAMP and more modern equvalent stacks. Johs > On 5. nov. 2015, at 11.48, Aurélien Bénel <[email protected]> wrote: > >> 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
