On Sep 5, 2011, at 7:50 PM, Sergiu Dumitriu wrote: > 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?
It's part of the work needed for the new model that I've continued working on (I'll start sending a mail about it soon now) but it's a feature that could be implemented first with the current model, making it easier to implement the new model API with the old model. It's not urgent but would be good to share a common vision and decide now if we want to have a global versioning strategy. Thanks -Vincent > >> 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
