[Nitro] Revisable -- is it the correct semantics??

Michael Fellinger manveru at weez-int.com
Tue Jun 27 22:35:23 EDT 2006

On Wednesday 28 June 2006 10:11, Dave Langston wrote:
> All,
> I hate semantic "wars... uh I mean discussions", and hopefully this one
> is trivial, but before I submit patches I would like to get a sense of
> the community re: 'revisions' which I am currenly using in a project I
> am implementing in Og/Nitro.

So to say, the nitro-community is totally open to discussions 
about 'semantics', we may try to outsmart each other once in a while, but 
when it comes to syntax everybody using ruby wants to save typing and 
thinking ;)
Anyway, the only rule here seems to be - 'make it optional/configurable' - no 
matter what your patch or feature is for, some people just don't want it or 
need total control over it...

> In Og glue/revisable.rb, currently (in 0.30.0 and George's repos) you
> "create" an 'item' and then you can "revise" an 'item' and by default
> the first version of the 'item' is assigned  a "revision" of 1
> (presently, the initial 'revision' value of the item is 'nil' and is
> then assigned a 'revision' value of 1 only after executing a "revise",
> at which time the newly created "revised" item is also assigned
> "revision" 1).  Interestingly, currently if you ask for
> item.revision_count  after the first 'revise', it will respond with '1'
> and item.last_revision will respond with the initial 'item' number 1....
> but if you ask for item.get_revision(1) you get the revised 'item'
> number 1...    from my view, we have inconsistent semantics of
> "revisions" here as well as possible bugs (also, I submitted a patch for
> what I thought was "the" revisioning bug last week which assigns the
> 'revised' item a revision number of 2, but the more I use it the more I
> see it is a larger issue)...
> So, let's quickly assume we are talking about a Document... I create a
> document (a), I  then revise the document (b), and I then revise the
> document again (c).  What are our semantic options:
> A) From one perspective I have an original document with "2" revisions,
> so the revision count is 2, the first revision is (b), the last revision
> is (c) and the initial doc (a) HAS NO REVISION number as it is the
> original (possibly revision "0"???).

I am all for this solution, would make it easy to use stuff like

class Page
  is Reviseable
  property :title, String
  property :text, String

page = Page.create_with :title => 'hello world' :text => 'puts "Hello World!"'
# this should be revision 0
# revision 1 - yes, i want automagic revising...
page = Page.first
# revision 1 - automagic call of last_revision?
page.revision 0
# revision 0

> B) From another perspective I could say I have 3 revisions (a) is
> revision 1, (b) is revision 2, and (c) is revision 3 and the revision
> count is 3
> Frankly, from my standpoint, perspective (B) is preferable from the way
> I see myself typically using the feature, but it is slightly confusing
> semantically.  It is clearer if one calls the process "versioning" and
> you have 3 versions of the document, but now not only does this require
> some patches, but requires renaming the feature as well or worse case,
> requires fixing 'revisioning' and creating a new feature,
> 'versioning'....  AHHHHH!!!
> thoughts from George as to his initial intent and the community at large??
> rgds,
> Dave Langston
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

More information about the Nitro-general mailing list