[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: GSoC Proposal - Versioning within OpenDocument files
From: Pierre Stirnweiss <pstirnweiss () googlemail ! com>
Date: 2009-03-17 8:23:41
Message-ID: af76e3dc0903170123i7c5b6638hffad0286158c4916 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
To summarise the discussions I had with Pierre(Pinaraf) and on the main
channel (which also involved Cyrille), there are two types of versioning:
- the basic one which would simply store a complete "odf file" of each
version in a sub-directory. This is how OOo is doing it. The advantage is
that it does not really impact the rest of the suite. The disadvantages (to
my mind) are that first redundant information is stored (and in the case of
OOo implementation, if I remember properly, as compressed zip inside the
zipped file), and second that it does not allow workflow like version
control system allows (revert commits, commits history, ...).
- the (to my mind) better system would be linked with the change traking
system. It could store which set of changes belong to which version. This
would allow more complex workflow of the versioning system (closer to what
version control allows). This is however far too complicated for a GSoC and
more importantly, there are unfortunatly, today, some blocking points to
such a system.
The first comes from the odf spec itself: tracking a format change is
reduced to tracking that a format change took place. This means that on
changing for example italic from false to true, the affected fragment will
be tagged with a "format changed region" but the information about what
change actually took place (italic, was false, is true) is not saved in the
odf spec. This is a must have if we want to implement more than the basic
versioning. I already have some ideas on how we could get around the
problem, but the ideal solution would be an evolution of the spec.
The second limitation is the change tracking itself. As the versioning
would store set of tracked changes, the change tracking system must be there
(and complete) first. When I say complete, this means not only text changes
are tracked, but also frames, images,... As previously mentioned, this is
what I will be working on mainly when the freeze is over, because that is
for me one of the building bricks of further evolutions towards a
"colaborative framework".
Ultimatly I think that the two are not necessarily mutually exclusive. If
you take an analogy with archiving, the basic system could be used to do the
"snapshot backup", whereas the change-tracking-based system could do the
"incremental backup". Or one could also think of the basic system as a way
to do a "snapshot branch".
Pierre(St)
[Attachment #5 (text/html)]
<div class="gmail_quote"><div>To summarise the discussions I had with Pierre(Pinaraf) \
and on the main channel (which also involved Cyrille), there are two types of \
versioning:<br><br>- the basic one which would simply store a complete "odf \
file" of each version in a sub-directory. This is how OOo is doing it. The \
advantage is that it does not really impact the rest of the suite. The disadvantages \
(to my mind) are that first redundant information is stored (and in the case of OOo \
implementation, if I remember properly, as compressed zip inside the zipped file), \
and second that it does not allow workflow like version control system allows (revert \
commits, commits history, ...).<br>
- the (to my mind) better system would be linked with the change traking system. It \
could store which set of changes belong to which version. This would allow more \
complex workflow of the versioning system (closer to what version control allows). \
This is however far too complicated for a GSoC and more importantly, there are \
unfortunatly, today, some blocking points to such a system.<br> The first comes from \
the odf spec itself: tracking a format change is reduced to tracking that a format \
change took place. This means that on changing for example italic from false to true, \
the affected fragment will be tagged with a "format changed region" but the \
information about what change actually took place (italic, was false, is true) is not \
saved in the odf spec. This is a must have if we want to implement more than the \
basic versioning. I already have some ideas on how we could get around the problem, \
but the ideal solution would be an evolution of the spec.<br> The second limitation \
is the change tracking itself. As the versioning would store set of tracked changes, \
the change tracking system must be there (and complete) first. When I say complete, \
this means not only text changes are tracked, but also frames, images,... As \
previously mentioned, this is what I will be working on mainly when the freeze is \
over, because that is for me one of the building bricks of further evolutions towards \
a "colaborative framework".<br> <br>Ultimatly I think that the two are not \
necessarily mutually exclusive. If you take an analogy with archiving, the basic \
system could be used to do the "snapshot backup", whereas the \
change-tracking-based system could do the "incremental backup". Or one \
could also think of the basic system as a way to do a "snapshot \
branch".<br> <br>Pierre(St)</div></div><br>
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic