My response #1.
Marc
attached mail follows:
On Thu, 2008-07-24 at 23:56 +1000, Martin Sevior wrote:
> On Thu, Jul 24, 2008 at 11:47 PM, J.M. Maurer <uwog@uwog.net> wrote:
> >
> > On Thu, 2008-07-24 at 23:37 +1000, Martin Sevior wrote:
> >> Hi Marc,
> >> My lack of enthusiasm for this idea is based on me trying
> >> to understand TF's PT code to do with revisions. It's not the least
> >> bit clear that what we think is happening actually is happening. For
> >> example I *thought* that every operation with Revision Marks enabled
> >> actually carries around a revision mark attribute.
> >
> > operation == CR?
> >
>
> No, the CR has the property but it didn;t get carried into the
> Attributes/ of the span. So for example if I turn on revision marks
> then insert some text, the the attribute "revision" exists with the
> value 1 is exprted to the listeners but it is not carried around in
> the text span I insert.
Makes sense.
> > If so, how are Rev. Marks stored right now in the PT ?
> >
>
> I'm not sure. I'm still trying to work that out. I think they're
> document level property that is interogated on every PT change.
Looking at how we store the revision marks, I think you are correct.
<revisions show="1" mark="1" show-level="0" auto="0">
<r id="1" time-started="1216908197" version="0">rev1</r>
<r id="2" time-started="1216908220" version="0">rev2</r>
</revisions>
> >> It turns out this was the not the case. Part of my surgery on the PT so far is to make
> >> sure this property IS set for at least remote revision marks.
> >
> > What property do you actually set on 'what' _exactly_ (talk in code form
> > please, maybe then I have an easier time to understand :p)
> >
>
> The attribute is "revision". It is meant to tell you the level of each
> revision. I've have been using "level" to represent different users in
> an abicollab context but actually I think TF's code is more subtle
> than that. I believe his code that level 1 is the first set of
> revisions. Level 2 is the second, level 3 is the third and so forth.
> Note that this assumption is that each level comes after each other.
> ie there is a heiracy of revisions. We can accept all revisions up to
> level n for example.
Yes indeed. revisions are stacked on top of eachother. So your attempt
to give every use a number would fail.
> Note these semantics are different from what we do in abicollab where
> all users are in principle equal.
>
> So I'm not sure our current revision marks make sense in the context
> of abicollab now.
>
> We should dump this conversation onto abiword-dev BTW
I think they still do. However, we need to think about revisions a lil'
different:
1. Every full collaboration session (from the point where the document
is first shared, to when it is last closed), should be considered *1*
revision. So not every user joining bumps the revision number.
2. Within a revision, we need a way to differentiate who did what, and
base the coloring of the text on _that_ property, rather than on the
revision number. Note that if implemented like this, the
non-collaboration revision mode would work with this new model. You just
have that 1 extra, in theory redundant, property.
Marc
> Cheers
>
> Martin
>
> >> I think
> >> that TF makes many, many implicit assumptions that there is only one
> >> set of revision marks present at one particular PT context, which
> >> makes perfect sense from his point of view of when he wrote that code
> >> but screws us now when we want to record who wrote what when.
> >
> > How can there be more than 1 set of revision marks on 1 PT context in
> > our case? Only one user will have touched 1 part, just like in the old
> > case. I have the feeling i miss something :)
> >
> >> I think he did it to avoid the elaborate potential mess with the
> >> document format you talked about.
> >>
> >> Actually from the point of view of the total document size, it doesn't
> >> make that much difference in memory, but it likely greatly expands the
> >> size of the document file if we carry around that sort of history.
> >>
> >> Part of my reason for wanting to do the property marking is because it
> >> maps much more closely to how abicollab works. I still haven't worked
> >> out how tf's revision marks really work. Only that don;t do what I
> >> thought they did.
> >
> > Cheers1
> >
> > Marc
> >
> >> Cheers!
> >>
> >> Martin
> >>
> >> On Thu, Jul 24, 2008 at 10:51 PM, J.M. Maurer <uwog@uwog.net> wrote:
> >> >
> >> > On Thu, 2008-07-24 at 22:10 +1000, Martin Sevior wrote:
> >> >> Hi Marc,
> >> >> Revision marks suck when you try to delete stuff because
> >> >> the text gets crossed out rather than deleted.
> >> >
> >> > That's why I mentioned the suggestion of adding a switch, to not
> >> > _display_ the deleted (or otherwise modified) text.
> >> >
> >> >> I finally got the
> >> >> revision marks coming out as different colors but then realised that
> >> >> we have significant issues with revision marks and deletes. Since the
> >> >> text isn't deleted, our adjustment calculations are incorrect with
> >> >> revision marks on.
> >> >
> >> > Oh jolly :-P Where do you plan on fixing this? I think this needs to be
> >> > fixed in abicollab's packet length calculation functions.
> >> >
> >> >> I still prefer the different colors and the remote property since that
> >> >> info is different from Revision Marks. It's actually a different
> >> >> feature.
> >> >
> >> > I don't see how it is different (in fact, it is _exactly_ what we
> >> > want):
> >> >
> >> > * revision marks track which user changes what
> >> > * with abicollab we want to track who changes what
> >> >
> >> > :) In fact, it is even more powerful: we also keep track of what the
> >> > previous content was, which rocks for "web based diff viewing"!
> >> >
> >> > Using rev. marks for this really sets of a party in my head (note: I
> >> > used to dismiss it, because it also shows crossed out text and such; but
> >> > we can make that a setting). Think about it :)
> >> >
> >> > Marc
> >> >
> >> >> Anyway will chat on IRC about this.
> >> >>
> >> >> Cheers
> >> >>
> >> >> Martin
> >> >>
> >> >>
> >> >> On Thu, Jul 24, 2008 at 8:25 PM, J.M. Maurer <uwog@uwog.net> wrote:
> >> >> >> IMO every such solution is a bit annoying. How about always enabling our
> >> >> >> 'revision tracking' feature, and making sure that it can detect where
> >> >> >> the edit came from (local or remote). We already have that info in the
> >> >> >> CRs now, so we wouldn't need any wire or file format change. Every is in
> >> >> >> place *right now*. And finally: this feature was designed _explicitely_
> >> >> >> to do what we want now. We just didn't know it back then :)
> >> >> >
> >> >> > The only issue left I see with this, is that when you enabled the
> >> >> > 'revision coloring', it also shows the text that "was there previously".
> >> >> > That would be a bit annoying in a collaboration session, if you 1) do
> >> >> > want to see the colors 2) don't want to see all the 'old' text.
> >> >> >
> >> >> > We could just add an extra switch to 'show the colors, but hide the old
> >> >> > crap'.
> >> >> >
> >> >> > The cool thing with this is that all this revision info is currently
> >> >> > stored in our file format. That means that the webinterface should also
> >> >> > be able to parse it out, and show a nice colored diff in the webapp :)
> >> >> >
> >> >> > Marc
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
Received on Thu Jul 24 16:18:44 2008
This archive was generated by hypermail 2.1.8 : Thu Jul 24 2008 - 16:18:44 CEST