[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Change Tracking and Epochs.
Hi, When I mention change tracking to some folks it has been mentioned a few times the interplay between revision control systems like git and the proposals. This got me thinking a bit and it strikes me that using git for ODF change tracking is somewhat like widening the ECT "buckets" to a whole document granularity. Thinking further, long life documents might call for the intermixing of both technologies -- revision control and change tracking in content.xml. Consider a document which lives in one version or another for 10-20 years and undergoes changes fairly frequently. In this case one might wish to be able to use both a revision control system like git and content.xml change tracking together. As a concrete example, one might want to have say, 20 revisions, and then at some point there have an acceptance stage for the document. This document might be checked into git first, then accepted and revisions set to number 21 with all changes coalesced into a single version (21). From there new changes would continue at 22. It would however be nice for the delta:tracked-changes to retain the revision 1-20 information and some link to where to get that epoch of the document. So if, in 10 years time I want to see what happened now I can grab the document with those changes in it and open it up for inspection. This document epoch might perhaps include revisions 6540 to 6630. Conversely, when dealing with adding new changes to that document in 10 years time, the application only deals with say the last 20-50 revisions, keeping complexity manageable for long life mutable documents. Retaining the delta:tracked-changes block should allow applications to compare documents from multiple epochs. Though this sort of thing calls for the merging of two document scope "buckets" and is likely a rather complex thing that a specialised application would have to handle. Having a constraint that a start of a new epoch MUST be a coalesce only operation would help because you would know that collectively the epoch with revision 1-20 in it should be isomorphic at revision 20 to revision 21 in the next epoch. ie, no changes should be performed between 20 and 21. Another nice feature of retaining the delta:tracked-changes for coalesced version numbers is that analysis could reveal the time frames that various users contributed to a document. So they can pull up the last changes that John Doe made 3 years back. Though a system like git would also allow this sort of enquiry, though this falls outside the shell of the ODF file itself. I'm not sure if this would be desired at the spec level or just left up to implementations to piece together as they wish. But at the spec level it might be nice to at least be able to explicitly indicate that a delta:change-transaction element represents a coalesced revision to avoid confusing applications.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]