-
1. Re: Versioning confusion
bcarothers May 6, 2010 3:51 PM (in response to kevin.thorley)What kind of repository are you using? The FileSystemRepository and SvnRepository don't have the ability (out of the box) to store arbitrary properties like jcr:mixinTypes, so they drop those properties silently at save time.
-
2. Re: Versioning confusion
kevin.thorley May 6, 2010 4:03 PM (in response to bcarothers)I am using the svn repository. When you say "out of the box", do you mean there is additional configuration that can be done to enable this? Or there needs to be more work done in code to support it?
Thanks,
Kevin
-
3. Re: Versioning confusion
bcarothers May 6, 2010 4:20 PM (in response to kevin.thorley)Both.
To add some context, neither the file system connector nor the SVN connector was intended to store arbitrary JCR data. They were really meant to expose existing content on your network as JCR (or expose certain kinds of content to external systems on the network). In a lot of cases, that would be enough. If you needed to do more (e.g., version the data), you could always copy that content into another part of a federated source that mapped to a different underlying connector.
The FileSystemConnector was actually expanded to allow storage of arbitrary properties through the CustomPropertiesFactory. It takes a little bit of code and configuration to set it up, but it's not particularly hard. The SvnConnector doesn't support CustomPropertiesFactory yet, but it could be made to do so.
I think there's a bit of a disconnect at times for people coming from a JR background. In JR, the file-backed repository is a very common repository for storing arbitrary data on a local file system. In MS, the FileSystemRepository is a bridge to the file system that only stores nt:files and nt:folders by default (with no mixins allowed). IMHO, the closest MS equivalent to the JR file repository is an Infinispan repository with a write-through cache.
The simplest alternative to set up though at the moment is a JpaConnector using the SimpleModel. That will durably store any kind of JCR content in almost any database supported by Hibernate.
-
4. Re: Versioning confusion
kevin.thorley May 6, 2010 4:28 PM (in response to bcarothers)Maybe I should give a brief overview of what I'm trying to accomplish. We have a rather large svn repo holding config data (a mix of .xml and .property files). For several reasons we would like to move away from the current model, especially in terms of requiring all clients of this data to have a local svn view. My first look was at JR, migrating our file-based svn system to a node-based JCR system backed by a MySql database. Now I am looking at ModeShape for comparison. The advantage of ModeShape is that we could connect to our existing svn repository and skip the data migration step. However, we will still need access to the versioning capabilities of subversion. If this is not supported via mixins in MS, is there another way to access previous versions of a document (Node)? Or is only the head of the repository accessible?
Thanks,
Kevin
-
5. Re: Versioning confusion
bcarothers May 7, 2010 9:11 AM (in response to kevin.thorley)Thanks for the additional context! Let me start with the pros and cons of the SVN connector...
The only way to persist a content change to an SVN repository is, of course, to commit it - so JCR saves() end up corresponding to SVN commits. We've kicked around the idea of mapping JCR checkins to SVN versions, but that gets a wee bit complex, since JCR mandates its own storage structure for versions.
Are you looking to be able to view the SVN history of a node from within the repository, or are you just trying to preserve a known-good way to rollback to a previous version?