5 Sep
2011
5 Sep
'11
6:31 p.m.
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
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.
More notes:
* This would also allow us to rollback before a given date
* If we wanted we could easily add the notion of Tags later on, i.e. to associate a name
with a VERSION
* 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?
Is there anything Git can tell us re managing versions that would be useful to this
discussion?
Thanks
-Vincent
5 Sep
5 Sep
7:50 p.m.
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/
13 Sep
13 Sep
2:54 p.m.
On Sep 5, 2011, at 7:50 PM, Sergiu Dumitriu wrote:
On 09/05/2011 12:31 PM, Vincent Massol wrote:
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
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/ 
3:04 p.m.
On Mon, Sep 5, 2011 at 6:31 PM, Vincent Massol <vincent(a)massol.net> 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
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.
More notes:
* This would also allow us to rollback before a given date
* If we wanted we could easily add the notion of Tags later on, i.e. to associate a name
with a VERSION
* 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?
See lots of benefits and a bit of complexity for the implementation
but should not be overwhelming.
Is there anything Git can tell us re managing versions
that would be useful to this discussion?
I think we looks more like svn than git.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
4967
days inactive
4975
days old
3 comments
3 participants
participants (3)
-
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol