regarding the architecture: basically is (or is very much like) event sourcing, right? I mean, kind of like an append-only log, that will grow forever.
Yes, that's right, at least at the source of truth on the server. Clients automatically rewrite or squash their local history a little bit prior to pushing it to the server to minimize log length and to avoid showing intermediate editing states that were never communicated to anyone else (just like you might squash git commits), but every important state is preserved in the log.
> Yes, that's right, at least at the source of truth on the server.
I assume the server holds human-readable issue id's, but clients do not then (until they are pushed to the server).
Do you assign just random guids to issues on the clients and then issue running issue numbers to them once they are on the server? If so, if I enter two issues on the client side with a reference from one to the other, how do I enter the cross-reference before I have the (server issued) issue id for either issue?
ok tnx!
as a dev myself, i'm still not convinced about this whole append-only/time-machine approach (i'm talking more about event sourcing in general, not your specific architecture). it smells too much architecture astronaut (see http://www.joelonsoftware.com/articles/fog0000000018.html and http://www.joelonsoftware.com/items/2008/05/01.html).
it feels like this incredibly heavy monster system that theoretically may let you do anything, but in practice, at the end of the day, is not able to do it because it is impractical to use.
again, not necessarily yours.
