AVM

Document created by resplin Employee on Jun 6, 2015Last modified by alfresco-archivist on Aug 31, 2016
Version 6Show Document
  • View in full screen mode

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com



{{AVMWarning}}
AVM


Overview


Alfresco's AVM (Advanced Versioning Manager) versioned repository can act like a virtual time machine.  For example, if you want to look at how a particular file appeared one month ago, you'll be able to see it against the backdrop of how everything else looked one month ago too.   The state of the entire repository will be recorded in an efficient manner at each moment in its transaction history.


How it works


The ability to travel through time in the file system can be achieved by 'directory versioning'. Essentially, whenever you create a new version of a file (or directory), the directory containing this modified object gets versioned too; then, the container of that directory is versioned (...and so on), until the very top of the file system is reached.  Ultimately, when an additional version of the top-level directory is created, it corresponds to a new moment in the global history of the entire repository.  As you continue to make further modifications, you'll generate more of these top-level directory objects; however, you'll only see the most recent one by default (i.e.: the file system as it is now).  The others remain available as read-only virtual 'snapshots', and can be accessed efficiently; you won't need to do lengthy 'checkout' operations just to see them.


Related Systems


Comparing content management systems is difficult; even good-faith efforts are bound to be somewhat incomplete, and out of date.  However, points of reference can be helpful when considering the core repository in isolation, so here are two:


Subversion


Alfresco's versioned repository is similar to Subversion in several areas:


  • Directories, renames, and file meta-data will be versioned
  • Atomic commits
  • Branching will be a constant-time operation



However, Alfresco's core repository has certain properties that Subversion does not:


  • Every moment in transaction history is available immediately as a read-only file system
  • Choice of database backends  (e.g.: MySQL, Oracle, PostgreSQL)
  • The absence of extraneous files; you only see the files you create (not the CMS)




TeamSite


Areas of similarity:


  • Every moment in transaction history is available immediately as a read-only file system
  • Directories, renames, and file meta-data are versioned
  • Branching is a constant-time operation



However, Alfresco's core repository has certain properties that TeamSite does not:


  • All directories are first-class versioned objects (much like Subversion)
  • All transactions backed by a relational database (e.g.:  Oracle, MySql, ...)
  • Virtualization is achieved on the file-system level itself (not through an HTTP proxy)




DM's versioning system (ADM)


Areas of similarity:


  • Files are versioned



However, AVM has certain properties that ADM does not:


  • AVM can version files and folders, whereas ADM can only version files
  • AVM allows branching files and folders
  • AVM allows merging files and folders

Illustrated Example


Alfresco won't actually copy all the files in a directory when it wants to make a new version of that directory; it merely creates the illusion that it is doing so.  As much information is shared between 'snapshots' as possible.  This is done to improve performance and keep the system scalable.




Initial Condition


For example, suppose we had a directory named c that contained files d, e, and f:

 

directory_versioning_0.png

 


Directory Versioning


If we attempt to add a new file g to c, we'll actually add it to a lightweight clone of c that we'll refer to as c'.  This clone will share most of its contents with the old version of our c directory. Hence, let's call the 'copies' that c' has of d, e, and f  'virtual copies'; to illustrate the fact that these are lightweight 'virtual copies', let's connect them to c' using a dotted arrow:

 

directory_versioning_1.png

 


Recursive Versioning


Suppose though, that c itself were contained by directory b.  Now that we've created new version of c (c'), we'll need to create a new version of b to contain that;  let's refer to this new version of b as b':

 

directory_versioning_2.png

 

Hopefully, you're getting the idea by now.  The b directory may have contained any number of other children besides c, but we only need lightweight 'virtual copies' of those; again, let's denote that by using dotted arrows.  As you can see above, the only 'heavyweight' child of  b' is c'

 


Top-Level Objects


Let's suppose that b itself were contained in directory a, and that a is the top-level directory (e.g.: / on UNIX, and something like <drive-letter>:\ on Windows).  We'd have to play the same trick, one last time:

 

directory_versioning_3.png

 


The Big Picture


Thus, assuming a was the top-level directory in our file system we'd wind up with something like this:

 

directory_versioning.png

 

Users will typically only see the most current version of the file system (e.g.: a');  however, the system remembers how the entire file system looked at the end of each separate transaction.

Outcomes