jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Trivial Update of "JackrabbitFileVault" by TobiasBocanegra
Date Wed, 04 Sep 2013 00:14:30 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "JackrabbitFileVault" page has been changed by TobiasBocanegra:
https://wiki.apache.org/jackrabbit/JackrabbitFileVault

New page:
'''''work in progress'''''
----
<<TableOfContents(4)>>

== Overview ==
Jackrabbit FileVault introduces a JCR repository to filesystem mapping. The mapping is exposed
by and API and used by several tools:
 * JackrabbitVaultPackaging that defines a package including the files, configuration and
filter information that allows export/import packages of content. '''''only migrated parts
of the package support yet'''''
 * Vault Command Line Interface aka `vlt` that provides a subversion like utility to work
and develop with repository content.

The base of the Jackrabbit FileVault is the VaultFs which provides the api for accessing repository
through a filesystem like mapping.

{{%topic.attachments%/vault_api.png|Vault Overview}}

== How it works ==
Jackrabbit FileVault works similar to subversion. Usually you checkout a local copy of the
(partial) content of the repository and make modifications to it. Once you're finished you
upload the modified stuff again. The content is mapped to a local filesystem structure using
the JcrFs API. The mechanism works like subversion where you have a copy of the unmodified
file and some information about the entries.

== Subversion & Vault living together ==
One of the goals of Jackrabbit FileVault is to provide the ability to store repository content
in a SCM for example in subversion. One problem occurs that the '''control files''' of vault
are not to be checked into subversion since this could cause problem in concurrent development.
Those files are kept in the `.vlt` directory which must be excluded from subversion. Using
the `svn:ignore` property is not advisable because one can forget to define it. A better option
is to use the `global-ignores` option in the subversion user configuration: 

{{{
...
### Section for configuring miscellaneous Subversion options.
[miscellany]
### Set global-ignores to a set of whitespace-delimited globs
### which Subversion will ignore in its 'status' output, and
### while importing or adding files and directories.
global-ignores = .vlt 
...
}}}

=== Use Cases ===
The following workflows illustrate that the Vault/Subversion coupling works and could easily
be automated. Plans are to propagate additions and removals automatically using javahl or
a similar java-svn binding.

Imagine the following scenario:
 * The application XYZ has some repository content that is exported and stored in subversion
 * User A and B both have a local checkout 
 * User A and B work with local test repositories

'''Workflow 1 - Modification:'''
 # User A does a fix in a jsp, checks it into his local repository and tests if the fix works
 # User A commits the jsp into subversion
 # User B update this copy via subversion and gets the modifications of the jsp
 # User B can now checkin the modifications to his local repository

'''Workflow 2 - Addition:'''
 # User A creates a new file on his local filesystem
 # User A uses `vlt` to add and commit it to his local repository
 # User A also adds the file to his subversion working copy and commits it
 # User B updates subversion and gets the new file
 # User B updates vault and notifies that this new file is not added to the vault yet
 # User B adds the file as well to his vault and commits it to the repository. 

'''Workflow 3 - Deletion:'''
 # User A deletes a file using `vlt`. This marks the file as deleted and removes it from disk
 # User A commits the changes to his local repository
 # User A marks the file as deleted using =svn= and commits the changes
 # User B updates subversion which deletes his local copy
 # User B marks the file as deleted using `vlt` and commits the changes to his local repository

== Export/Checkout directory structure ==
The root directory of a vault checkout contains a `META-INF/vault` directory which holds the
serialization configuration (`config.xml`) the filter information (`filter.xml`) and other
settings. The repository content is placed in a directory named `jcr_root`. eg:

{{{
+ mycheckeout
  + META-INF
  + jcr_root
}}}

=== `META-INF/vault/config.xml` ===
Contains the VaultFs configuration that is (was) used for this checkout (export).

{*} TODO: Add example

=== `META-INF/vault/filter.xml` ===
Contains the workspace filter that is (was) used for this checkout (export).

{*} TODO: Add example

== User specific config files ==
Some configuration files are stored in the user's home directory. usually under `~/.vault`.

=== `~/.vault/settings.xml` ===
Holds some per user configuration like globally ignored files, etc.

{*} TODO: Add more info

=== `~/.vault/auth.xml` ===
Holds authorization information for known repositories.

{*} TODO: Add more info

== Usage ==
The console tool is called `vlt` and has the following usage:
 
{{{
$vlt --help

----------------------------------------------------------------------------------------------
Jackrabbit FileVault [version 3.0.0] Copyright 2013 by Apache Software Foundation.
See LICENSE.txt for more information.
----------------------------------------------------------------------------------------------
Usage:
  vlt [options] <command> [arg1 [arg2 [arg3] ..]]
----------------------------------------------------------------------------------------------

Global options:
  -Xjcrlog <arg>           Extended JcrLog options (omit argument for help)
  -Xdavex <arg>            Extended JCR remoting options (omit argument for help)
  --credentials <arg>      The default credentials to use
  --config <arg>           The JcrFs config to use
  -v (--verbose)           verbose output
  -q (--quiet)             print as little as possible
  --version                print the version information and exit
  --log-level <level>      the log4j log level
  -h (--help) <command>    print this help
Commands:
  export                   Export the Vault filesystem
  import                   Import a Vault filesystem
  checkout (co)            Checkout a Vault file system
  status (st)              Print the status of working copy files and directories.
  update (up)              Bring changes from the repository into the working copy.
  info                     Displays information about a local file.
  commit (ci)              Send changes from your working copy to the repository.
  revert (rev)             Restore pristine working copy file (undo most local edits).
  resolved (res)           Remove 'conflicted' state on working copy files or directories.
  propget (pg)             Print the value of a property on files or directories.
  proplist (pl)            Print the properties on files or directories.
  propset (ps)             Set the value of a property on files or directories.
  add                      Put files and directories under version control.
  delete (del,rm)          Remove files and directories from version control.
  diff (di)                Display the differences between two paths.
  rcp                      Remote copy of repository content.
  sync                     Control vault sync service
  console                  Run an interactive console
----------------------------------------------------------------------------------------------
}}}

{*} TODO: Add more info

Mime
View raw message