[prev in list] [next in list] [prev in thread] [next in thread]
List: koffice-devel
Subject: Re: GSoC Proposal - Versioning within OpenDocument files
From: Pau Garcia i Quiles <pgquiles () elpauer ! org>
Date: 2009-03-17 23:19:08
Message-ID: 3af572ac0903171619i3aa3e764t6abc607607648bf () mail ! gmail ! com
[Download RAW message or body]
Hello,
I'm working on a more general solution to document versioning.
First, I'm developing libQtGit, which provides a Qt-like API to use
git. Unfortunately, it's been on hold for three months because I was
too busy with real work. The good news is last Monday I started
hacking on it again.
Second, I intend to develop a framework (tentatively named QVersioned
for now) on top of libQtGit. QVersioned will provide QVersionedDir and
QVersionedFile classes (amongst others, but those two are the most
important). Those classes would essentially have the same API QDir and
QFile. QVersioned would open ZIP files and store a .git directory
inside. There are cases, like ODF (which itself is a ZIP file) where
nothing special is needed. For other cases (for instance, a .txt
file), there would be a .txtv (meaning ".txt versioned") which would
be a ZIP fiel containing the .txt + .git directory.
Now, how did I intend to implement ODF versioning, which was going to
be the "this thing works" case?:
- The .git folder would store the uncompressed contents of the ODF
file, i. e. XML, images, etc. This is needed to avoid duplication,
allow diffs, etc
- There would be also a full copy of the latest version (XML, images,
etc) in the ZIP file, just like any ODF-capable application not
supporting QVersioned would expect (these applications would just
ignore the .git directory)
- When a QVersioned-capable application opens an ODF file, it compares
the XML, images, etc to the latest version in git:
* If the diff is empty, last save was by a QVersioned-capable application
* If the diff is not empty, last save was by a QVersioned-incapable
application. A new "git commit -a" is performed. Yes, we probably have
lost "versions" of the document in between this commit and the former
one but something's better than nothing.
By using libQtGit and QVersioned, it would also be possible to add
collaboration features such as "send me an update" (i. e. send me a
diff which transforms my outdated document into your latest version),
collaborative editing (send diffs back and forth) and more things I
cannot think of right now.
In case you are interested in the libQtGit API (remember QVersioned
will offer a higher-level API), this is the signature of the method
you would call:
Git::Repository::Commit* Git::Repository::commit ( const
QString& message = QString(),
const Commit* c = 0,
const QString& author = QString(),
const CommitFlags cf = DefaultCommitFlags,
const CleanUpMode cum = DefaultCleanUpBehavior );
That's equivalent to "git commit -C commit_id -m "message" ".
CommitFlags is a QFlags and CleanUpMode a QEnum:
enum CommitFlag {
DefaultCommitFlags = 0x0 /*< git commit */,
OverrideIndexCommit = 0x1 /*< git commit -a */,
SignOffCommit = 0x2 /*< git commit -s */,
AmendCommit = 0x4 /*< git commit --amend */,
AllowEmptyCommit = 0x8 /*< git commit --allow-empty */,
NoVerifyCommit = 0x16 /*< git commit -n */
};
Q_DECLARE_FLAGS ( CommitFlags, CommitFlag )
enum CleanUpMode {
DefaultCleanUpBehavior = 0x0 /*< git commit */,
VerbatimClean = 0x1 /*< git commit --cleanup=verbatim */,
WhiteSpaceClean = 0x2 /*< git commit --cleanup=whitespace*/,
StripClean = 0x4 /*< git commit --cleanup=strip */,
DefaultClean = 0x8 /*< git commit --cleanup=default */
};
Q_ENUMS ( CleanUpMode )
For the "git commit -a -m "Save latest unversioned version on ODF
document opening" ", we would use:
// Assuming 'repo' is a valid Git::Repository object
repo->commit ( "Save latest unversioned version on ODF document opening",
0,
"(The application would probably take the
author's name from the product registration)",
Git::Repository::OverrideIndexCommit );
So, how is libQtGit doing? Well, the API is there for X git add,
commit, init, mv, rm, checkout, clone, branch, revert, reset, clean,
gc, status, merge, push, fetch, pull, rebase, config,
update-server-info and (partially) symbolic-ref. When I say "the API
is there" I mean "all the QFlags, QEnums, methods, classes and its
translation to git parameters is done". It's just a matter of
implementing the QProcess part, parsing output, etc. Boring and
time-consuming but easy.
Sorry if I diverged too much from the OP.
On Mon, Mar 16, 2009 at 4:48 PM, Nicholas Sinlock
<isolatedincident@gmail.com> wrote:
> Hi, I'm going to be applying for the GSoC with KDE/KOffice and I was
> hoping I might get some feedback on my proposal from the developers of
> KOffice.
> Any suggestions or criticisms would be immensely valuable. Thanks!
> *
> *
> *Summary*
>
> As developers, we are all too aware of how useful keeping multiple
> versions of a file can be. OpenOffice.org currently features a similar
> ability to save multiple
> versions within a single OpenDocument file. This is potentially very
> useful to end users as it allows for them to maintain multiple versions,
> without the hassle of
> maintaining and organizing multiple files. I believe KOffice, if it
> wants to compete with OpenOffice.org, ought to offer this great feature
> to their users.
>
> The ability to save versions is wholly separate from the ability to save
> a file. While a file may be a version, the ability to hold multiple
> version of a file concurrently
> within one single file is much more useful. Now there are six
> different OpenDocument file formats, four of which are used by
>
> *Goals*
>
> My goal is to implement support for storing and retrieving multiple
> versions of a document, using only a single OpenDocument file. This will
> require adding this type
> of support for loading and saving versions within the KOffice
> applications which utilize one of the OpenDocument formats. This will
> enable the user to store multiple
> versions of the same document without having to save multiple files and
> keep track of them. This is potentially useful for many reasons. One can
> experiment with
> edits to a document without having to worry about destroying the
> previous "good" version. With this feature, it should also be possible
> to make multiple versions of
> a single file, which differ only in their style--effectively allowing
> the user to try out the different styles easily. But beyond it's use to
> the users of KOffice, this feature
> will also allow KOffice to gain a feature which OpenOffice.org currently
> has.
>
> *Implementation**
>
> I am currently looking into two separate ways to implement versioning.
> The first method is to implement something like OpenOffice.org did,
> where there is a version
> list file which lists the information about the various saved versions
> and a separate folder where the information about the different versions
> are stored in separate
> "zip" files which contain their individual, complete version.
>
> The other option is to use the change tracking features within the
> current ODF v1.1 specification along with some additions to implement a
> versioning system that
> functions more like a version control system, tracking changes to
> individual sections of a document, than an archival system which retains
> copies of previous versions.
>
> *Time Line*
>
> I plan on spending the time running up to the start of the Google Summer
> of Code and the first week in deciding how best to implement versioning
> within a single
> OpenDocument file within KOffice. Once I've figured out how best to
> implement the feature, I will implement the ability within each
> application, starting out with
> the applications using the .odg and .odf formats, since there are
> approximately two applications which use the .odg and approximately
> three that use the .odf file
> formats. These should go faster since they could possibly share some of
> the code between the applications. I hope to have those done by the
> midterm, after which
> I will implement the support for KWord and .odt, KPresenter and .odp,
> and KSpread and .ods. This should be an attainable goal by the end of
> the Summer of
> Code, but, understanding that problems always occur in development, I
> plan to keep a flexible schedule. My ultimate goal is to implement as
> much of this capability
> within the summer, and to implement the rest during the fall.
>
> *Qualifications*
>
> I am a freshman/sophomore Computer Science student at the University of
> Maryland, College Park (www.umd.edu and www.cs.umd.edu). I have experience
> developing with C++ and Java and knowledge of Python and XML. In
> addition, I am familiar with the KDE, Qt and KOffice APIs and I am an
> active contributor
> to the KOffice project. I have submitted one patch for KWord, and am
> working on a second patch for KWord. This familiarity will allow me to
> begin work on
> the project quickly as I won't have to spend any time learning the Qt,
> KDE, or KOffice APIs.
>
>
> *My Implementation details are a little vague, as I haven't nailed down
> a specific implementation which is best.
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
>
--
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)
_______________________________________________
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