On 09/05/2011 12:31 PM, Vincent Massol wrote: > Hi devs, > > I'd like to brainstorm about the idea of having global versioning in XE. > > First here is a use case: > * I have a given state in my wiki with pages in different versions > * I add some pages or make modifications to existing pages > * I want to go back to the previous state
Yes, this is a valid usecase for a wiki with few users or with a highly centralized community/decision making process. See this old issue as well: http://jira.xwiki.org/browse/XE-63 > A good use case could be for example to return to a state before one or > several applications have been installed. > > Proposed solution > ============== > > * Store a global version number in the DB. Let's call it VERSION > * Whenever a doc is modified, use VERSION + 1 as the new doc version > * When we rollback (to say version OLDVERSION) do a query on all docs in the > wiki having a version> OLDVERSION and for each of them rollback to their > last version<= OLDVERSION > * Write a migrator that runs the whole wiki history by looking at all > versions of all docs (map in memory) and recompute the new version starting a > VERSION = 1 and incrementing. > * We would also need to modify the XAR importer so that importing a XAR with > an older versioning scheme will work. BTW knowing that it's an old scheme is > relatively easy since all old versions have a dot in their name. I don't quite like this. A global version number could be even more confusing for users. Even the current version number are a bit confusing for non-technical users, but I think that seeing a large number jumping wildly in the history would be even more confusing. It has no apparent semantics, since users don't care about the global state of things, they care about their documents. If we want to thoroughly rethink the versioning scheme, let's do it right. Mediawiki does use a global counter for versions, but that counter is hidden. They use the date as the user-friendly identifier of a version. We could do the same, although I don't like the way Mediawiki presents the history from a UX POV. On the implementation side, I don't like the use of this global VERSION that must be manually incremented. It's hard to ensure uniqueness since we'd have to synchronize all the calls to it (atomic get and increment), plus more trouble when working in a cluster setup. Something a bit better would be to keep the same local versioning scheme for each document, but keep an index of the global versions, with a DB-managed autoincrementing index as the primary key. Whenever a new version is saved, add to this index a row pointing to the modified document and the target version. We can also store the author of the change, and even the current date, for easier filter on the global history (get me all the changes done by this compromised account between this and that date). One problem (or feature) with this is that the date in the index might be different than the date in the real version, for example when importing a backup XAR. > More notes: > * This would also allow us to rollback before a given date This should be an administrative feature. I wouldn't want a simple user rolling back his changes to make hundreds of other unrelated changes disappear. > * If we wanted we could easily add the notion of Tags later on, i.e. to > associate a name with a VERSION +1, this is indeed a nice feature, as long as we add deeper support for it, like continuous browsing on that tag. It would be very hard, if not impossible, to run a query on the state at a given time. But it could be emulated for some, like the event stream. > * I've been thinking about this in the context of the new model but it's > probably easier to implement it first with the old model > * JRCS uses the format X.Y for versions but we could decide to only use the > major, i.e always have versions of the form X.0 > * In order to continue to support minor edits we would need a way to save > that information. One solution is to use the minor to signify a minor edit, > for ex: X.1 would mean that X is a minor. Another, probably better solution > would be to store that information in the DB in the xwikircs table > > WDYT? Do you see any drawback of using a global versioning scheme? Do you > think this is doable or too much work? I don't think that this is an important feature at the moment. Is it something needed? > Is there anything Git can tell us re managing versions that would be useful > to this discussion? Not quite, since Git uses SHAs as version identifiers, which they need in order to support parallel branches and merging. > Thanks > -Vincent -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
