Versioning of domain model

I implement versioning for my own domain model (tracking of d开发者_如何学Cifferences in objects during update operations). Domain model has a tree structure. E.g. (-> is reference)

A
|-> B
|-> C -> A
    | -> C

Requirements for versioning are following:

• Get the set of changed fields between two versions of domain object;
• Domain model has a tree structure;
• Fields can be organized in lists. In following example system should show that Y element was removed (but not that Z was removed and Y changed its state on Z) and X was changed:

      [ v1 ]              [ v2 ]
        A                    A
        |-> [X, Y, Z]        |-> [X, Z]
             |-> C                |-> M

• There are no more requirements like locking/merging/branching.

I investigate the way to get change set between two states of the same object. I work with Java and interested in exist approaches/solutions. E.g. I'm looking for description of algorithm that subversion use to create next revision.

I will glad to get any theoretical or practical advice from your side.

Thanks

I suspect that your domain model is not represented using text files but as an object model most probably persisted in an relational database. We are at the moment designing just this and have already prototyped it.

My lessons learned:

1. You need an exact description of what features do you need for version control and which you don't need. Just logging the changes is easy, providing tagged versions and branches with exclusive locking is hard, providing a merge is very hard.
2. Logging could be realized at the db level using triggers. Create tables for all your domain objects and if an entry is added/edited/removed log the complete entry. Append information (time...) as needed. It might be needed that every user logs into the db as an own db user such that you can query the CURRENT_USER to log him.
3. Instead of logging before/after change edits you can log modifications of attributes. But this will create much more log entries and it is costly to gather all changes for a specific commit.
4. Locking of objects could be done with method calls (lock/unlock). Checking for the locks could be done at the db level using triggers again (get CURRENT_USER and check if he has locked the object). This has the advantage that user code hasn't to query if an object is locked but the database will prevent the insert/edit/delete. Not using locking would require you to implement a merge. This will be very hard as you are not working with text files but with highly structured data.
5. Incorporating versioning with your domain model might be surprisingly tricky. Especially if you require to not let leak versioning into your domain model (if you plan to reuse the versioning system). Prototype it!

Well, I would say, you speak of 2 different things here.

Subversion has a revision number for the complete tree, meaning every change is a cheap copy of the previous version. So, there's no changeset in the term you have in your object hierarchy. It's more the sum off all changes - and they are calculated per file by your usual diff mechanism.

If you need versioning for your persisted objects, I would add a version attribute in each and then a method per class calculating the differences. But maybe you'll need to tell us how you plan to use that information?