Arbitrary object model versioning?!

[Arrgh]

Hi folks,

I found SVNKit today as a result of a Google search and was immediately enticed by the promise of "arbitrary object model versioning."  However, I've been unable to figure out what such a thing would look like, after spending half an hour or so reading the wiki and javadoc and searching this list's archives.  Can anyone give me a high-altitude view of how this feature is envisioned to work?

Thanks!

-0xe1a

[Alexander Kitaev-3]

Hello,

 > list's archives.  Can anyone give me a high-altitude view of how this
 > feature is envisioned to work?
This is very good question, thank you.

So, the basic simple idea behind object model versioning is the way data
is stored in Subversion repository and the way we could use it for
something else rather then store files.

Subversion repository could be described as a sequence of revisions,
from revision 0 to revision X. Each revision is a tree of objects, where
each non-leaf node object has name and properties (in form of name=value
pairs) and leaf nodes additionally may keep raw data (sequence of bytes).

Technically, what is stored in repository are not revisions themselves,
but rather a differences (deltas) between them, i.e. rev0:1 difference,
1:2, etc. Each delta may refer to the previous revisions or may not.

So, working with repository is basically limited to two operations:

1) getting certain revision (tree of objects) from repository.
2) creating new revision (tree of objects) in repository.

In both cases one works with deltas - in case 1) client receives "delta"
between existing objects tree (which could be empty, like in case of
checkout) and tree represented by revision client would like to get.

In case 2) client creates new revision by describing the difference
between latest revision (tree) and tree client would like to create in
repository.

Subversion client uses above approach to manage files and directories,
but nothing prevents us from managing other object models (representable
as tree of objects).

Let's say you have a model that represents library with a books:

Library (owner = Ivan Pomidorov)
   Shelf 1 (theme = Russian Literature)
     Book 1 (author = FD, title = Crime and Punishment)
     Book 2 (author = LT, title = War and Peace)
     Book 3 (author = JB, title = Poems)

Totally four objects in the model. Each object has "path" ("Library' for
the root one, "Library/Shelf 1" for the first shelf and "Library/Shelf 1
/Book 2" for one of the books). We also know that latest repository
revision is 0, so we need to add (import) all our model into repository:

SVNRepository repos = SVNRepositoryFactory.create(URL);
ISVNEditor editor = repos.getCommitEditor("import", ..);
// now we'll describe delta - difference between revision 0, empty
// repository, and our model. This way we'll create revision 1 in
// repository
editor.openRoot(-1)

editor.addDir("Library", ...);
editor.changeDirProperty("owner", "Ivan Pomidorov");
editor.addDir("Library/Shelf 1", ...);
editor.changeDirProperty("theme", "Russian Literature");

editor.addFile("Library/Shelf 1/Book 1");
editor.changeFileProperty("author", "FD");
editor.changeFileProperty("title", "Crime and Punishment");
// here one may submit also some byte[] contents for that node,
// in this example it could be text of the book.
editor.closeFile(...);

editor.addFile("Library/Shelf 1/Book 2");
editor.changeFileProperty("author", "LT");
editor.changeFileProperty("title", "War and Peace");
// ...
editor.closeFile(...);

editor.closeDir(); // Shelf
editor.closeDir(); // Library

editor.closeDir();
editor.closeEdit();

We may keep revision number (now it is revision 1) as part of the local
model - to make sure we're not changing model that was changed by
someone else, without updating our local model first; production
application will probably require it, but in our example we may always
consider that we have the latest version of the model locally and it is
the same as the latest one in repository.

So, we added a book to the model, thus making model "locally modified".
Again, we probably will have to keep a flag in the model that will say
us whether we have modifications made locally after commit/update or not.

To add a book:

editor.openRoot(-1)

editor.openDir("Library", ...);
editor.openDir("Library/Shelf 1", ...);

editor.addFile("Library/Shelf 1/Book 3");
editor.changeFileProperty("author", "JB");
editor.changeFileProperty("title", "Poems");
editor.closeFile(...);

editor.closeDir(); // Shelf
editor.closeDir(); // Library

editor.closeDir();
editor.closeEdit();

Real application will probably do it in different way: it will traverse
model, collect nodes that has to be committed (modified, added, deleted)
and then will "drive" commit editor describing the "delta" to create new
revision in repository.

Update (or checkout operation) is a mirror of commit one - client
implements ISVNEditor, says to repository what revision does he have
locally and what revision it would like to get and then process update
instructions in its ISVNEditor implementation updating model (by adding,
deleting or modifying objects).

I hope this brief introduction helps. There are more things to know
about, but the basic idea is that Subversion protocol and repository
format doesn't require client to store files, so we may use it to
version something different (as long as it could be represented as a tree).

Also, google for "Shotoku" project developed by JBoss Labs - this is
experimental project the provides framework for wrapping existing object
models into, so that these models could be versioned within Subversion
repository.

Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!

Arrgh wrote:

> Hi folks,
>
> I found SVNKit today as a result of a Google search and was immediately
> enticed by the promise of "arbitrary object model versioning."  However,
> I've been unable to figure out what such a thing would look like, after
> spending half an hour or so reading the wiki and javadoc and searching this
> list's archives.  Can anyone give me a high-altitude view of how this
> feature is envisioned to work?
>
> Thanks!
>
> -0xe1a

---------------------------------------------------------------------
To unsubscribe, e-mail: svnkit-users-unsubscribe@...
For additional commands, e-mail: svnkit-users-help@...