SYNOPSIS

   fsvs command [options] [args]

   The following commands are understood by FSVS:

Local configuration and information:

   urls Define working copy base directories by their URL(s)

   status Get a list of changed entries

   info Display detailed information about single entries

   log Fetch the log messages from the repository

   diff Get differences between files (local and remote)

   copyfrom-detect
          Ask FSVS about probably copied/moved/renamed entries; see cp

Defining which entries to take:

   ignore and rign Define ignore patterns

   unversion Remove entries from versioning

   add Add entries that would be ignored

   cp, mv Tell FSVS that entries were copied

Commands working with the repository:

   commit Send changed data to the repository

   update Get updates from the repository

   checkout Fetch some part of the repository, and register it as working
          copy

   cat Get a file from the directory

   revert and uncp Undo local changes and entry markings

   remote-status Ask what an update would bring

Property handling:

   prop-set Set user-defined properties

   prop-get Ask value of user-defined properties

   prop-list Get a list of user-defined properties

Additional commands used for recovery and debugging:

   export Fetch some part of the repository

   sync-repos Drop local information about the entries, and fetch the
          current list from the repository.

   Note
          Multi-url-operations are relatively new; there might be rough
          edges.

   The return code is 0 for success, or 2 for an error. 1 is returned if
   the option Checking for changes in a script is used, and changes are
   found; see also Filtering entries.

Universal options

-V -- show version

   -V makes FSVS print the version and a copyright notice, and exit.

-d and -D -- debugging

   If FSVS was compiled using –enable-debug you can enable printing of
   debug messages (to STDOUT) with -d. Per default all messages are
   printed; if you're only interested in a subset, you can use -D
   start-of-function-name.
   fsvs -d -D waa_ status

   would call the status action, printing all debug messages of all WAA
   functions - waa__init, waa__open, etc.

   For more details on the other debugging options debug_output and
   debug_buffer please see the options list.

-N, -R -- recursion

   The -N and -R switches in effect just decrement/increment a
   counter; the behaviour is chosen depending on that. So a command line
   of -N -N -N -R -R is equivalent to -3 +2 = -1, this results in -N.

-q, -v -- verbose/quiet

   -v / -q set/clear verbosity flags, and so give more/less output.

   Please see the verbose option for more details.

-C -- checksum

   -C chooses to use more change detection checks; please see the
   change_check option for more details.

-f -- filter entries

   This parameter allows to do a bit of filtering of entries, or, for some
   operations, modification of the work done on given entries.

   It requires a specification at the end, which can be any combination of
   any, text, new, deleted (or removed), meta, mtime, group, mode, changed
   or owner; default or def use the default value.

   By giving eg. the value text, with a status action only entries that
   are new or changed are shown; with mtime,group only entries whose group
   or modification time has changed are printed.

   Note
          Please see Change detection for some more information.
          If an entry gets replaced with an entry of a different type (eg.
          a directory gets replaced by a file), that counts as deleted and
          new.

   If you use -v, it's used as a any internally.

   If you use the string none, it resets the bitmask to no entries shown;
   then you can built a new mask. So owner,none,any,none,delete would show
   deleted entries. If the value after all commandline parsing is none, it
   is reset to the default.

-W warning=action -- set warnings

   Here you can define the behaviour for certain situations that should
   not normally happen, but which you might encounter.

   The general format here is specification = action, where specification
   is a string matching the start of at least one of the defined
   situations, and action is one of these:
     * once to print only a single warning,
     * always to print a warning message every time,
     * stop to abort the program,
     * ignore to simply ignore this situation, or
     * count to just count the number of occurrences.

   If specification matches more than one situation, all of them are set;
   eg. for meta=ignore all of meta-mtime, meta-user etc. are ignored.

   If at least a single warning that is not ignored is encountered during
   the program run, a list of warnings along with the number of messages
   it would have printed with the setting always is displayed, to inform
   the user of possible problems.

   The following situations can be handled with this:
   meta-mtime, meta-user, meta-group, meta-umask

   These warnings are issued if a meta-data property that was fetched from
   the repository couldn't be parsed. This can only happen if some other
   program or a user changes properties on entries.
   In this case you can use -Wmeta=always or -Wmeta=count, until the
   repository is clean again.

   no-urllist

   This warning is issued if a info action is executed, but no URLs have
   been defined yet.

   charset-invalid

   If the function nl_langinfo(3) couldn't return the name of the current
   character encoding, a default of UTF-8 is used. You might need that for
   a minimal system installation, eg. on recovery.

   chmod-eperm, chown-eperm

   If you update a working copy as normal user, and get to update a file
   which has another owner but which you may modify, you'll get errors
   because neither the user, group, nor mode can be set.
   This way you can make the errors non-fatal.

   chmod-other, chown-other

   If you get another error than EPERM in the situation above, you might
   find these useful.

   mixed-rev-wc

   If you specify some revision number on a revert, it will complain that
   mixed-revision working copies are not allowed.
   While you cannot enable mixed-revision working copies (I'm working on
   that) you can avoid being told every time.

   propname-reserved

   It is normally not allowed to set a property with the prop-set action
   with a name matching some reserved prefixes.

   ignpat-wcbase

   This warning is issued if an absolute ignore pattern" does not match
   the working copy base directory. \n See \ref ignpat_shell_abs "absolute
   shell patterns" for more details.

   diff-status

   GNU diff has defined that it returns an exit code 2 in case of an
   error; sadly it returns that also for binary files, so that a simply
   fsvs diff some-binary-file text-file would abort without printing the
   diff for the second file.
   Because of this FSVS currently ignores the exit status of diff per
   default, but this can be changed by setting this option to eg. stop.

   Also an environment variable FSVS_WARNINGS is used and parsed; it is
   simply a whitespace-separated list of option specifications.

-u URLname[@revision[:revision]] -- select URLs

   Some commands can be reduced to a subset of defined URLs; the update
   command is a example.

   If you have more than a single URL in use for your working copy, update
   normally updates all entries from all URLs. By using this parameter you
   can tell FSVS to update only the specified URLs.

   The parameter can be used repeatedly; the value can have multiple URLs,
   separated by whitespace or one of ",;".

   fsvs up -u base_install,boot@32 -u gcc

   This would get HEAD of base_install and gcc, and set the target
   revision of the boot URL for this command at 32.

-o [name[=value]] -- other options

   This is used for setting some seldom used option, for which default can
   be set in a configuration file (to be implemented, currently only
   command-line).

   For a list of these please see Further options for FSVS..

Signals

   If you have a running FSVS, and you want to change its verbosity, you
   can send the process either SIGUSR1 (to make it more verbose) or
   SIGUSR2 (more quiet).

add

   fsvs add [-u URLNAME] PATH [PATH...]

   With this command you can explicitly define entries to be versioned,
   even if they have a matching ignore pattern. They will be sent to the
   repository on the next commit, just like other new entries, and will
   therefore be reported as New .

   The -u option can be used if you're have more than one URL defined for
   this working copy and want to have the entries pinned to the this URL.

Example

   Say, you're versioning your home directory, and gave an ignore pattern
   of ./.* to ignore all .* entries in your home-directory. Now you want
   .bashrc, .ssh/config, and your complete .kde3-tree saved, just like
   other data.

   So you tell fsvs to not ignore these entries:
   fsvs add .bashrc .ssh/config .kde3

   Now the entries below .kde3 would match your earlier ./.* pattern (as a
   match at the beginning is sufficient), so you have to insert a negative
   ignore pattern (a take pattern):
   fsvs ignore prepend t./.kde3

   Now a fsvs st would show your entries as New , and the next commit will
   send them to the repository.

unversion

   fsvs unversion PATH [PATH...]

   This command flags the given paths locally as removed. On the next
   commit they will be deleted in the repository, and the local
   information of them will be removed, but not the entries themselves. So
   they will show up as New again, and you get another chance at ignoring
   them.

Example

   Say, you're versioning your home directory, and found that you no
   longer want .bash_history and .sh_history versioned. So you do
   fsvs unversion .bash_history .sh_history

   and these files will be reported as d (will be deleted, but only in the
   repository).

   Then you do a
   fsvs commit

   Now fsvs would report these files as New , as it does no longer know
   anything about them; but that can be cured by
   fsvs ignore "./.*sh_history"

   Now these two files won't be shown as New , either.

   The example also shows why the given paths are not just entered as
   separate ignore patterns - they are just single cases of a (probably)
   much broader pattern.

   Note
          If you didn't use some kind of escaping for the pattern, the
          shell would expand it to the actual filenames, which is
          (normally) not what you want.

_build_new_list

   This is used mainly for debugging. It traverses the filesystem and
   builds a new entries file. In production it should not be used; as
   neither URLs nor the revision of the entries is known, information is
   lost by calling this function!

   Look at sync-repos.

delay

   This command delays execution until time has passed at least to the
   next second after writing the data files used by FSVS (dir and urls).

   This command is for use in scripts; where previously the delay option
   was used, this can be substituted by the given command followed by the
   delay command.

   The advantage against the delay option is that read-only commands can
   be used in the meantime.

   An example:
   fsvs commit /etc/X11 -m "Backup of X11"
   ... read-only commands, like "status"
   fsvs delay /etc/X11
   ... read-write commands, like "commit"

   The optional path can point to any path in the WC.

   In the testing framework it is used to save a bit of time; in normal
   operation, where FSVS commands are not so tightly packed, it is
   normally preferable to use the delay option.

cat

   fsvs cat [-r rev] path

   Fetches a file repository, and outputs it to STDOUT. If no revision is
   specified, it defaults to BASE, ie. the current local revision number
   of the entry.

checkout

   fsvs checkout [path] URL [URLs...]

   Sets one or more URLs for the current working directory (or the
   directory path), and does an checkout of these URLs.

   Example:
   fsvs checkout . http://svn/repos/installation/machine-1/trunk

   The distinction whether a directory is given or not is done based on
   the
   result of URL-parsing – if it looks like an URL, it is used as an URL.
   Please mind that at most a single path is allowed; as soon as two
   non-URLs are found an error message is printed.

   If no directory is given, "." is used; this differs from the usual
   subversion usage, but might be better suited for usage as a recovery
   tool (where versioning / is common). Opinions welcome.

   The given path must exist, and should be empty – FSVS will abort on
   conflicts, ie. if files that should be created already exist.
   If there's a need to create that directory, please say so; patches for
   some parameter like -p are welcome.

   For a format definition of the URLs please see the chapter Format of
   URLs and the urls and update commands.

   Furthermore you might be interested in Using an alternate root
   directory and Recovery for a non-booting system.

commit

   fsvs commit [-m "message"|-F filename] [-v] [-C [-C]] [PATH [PATH ...]]

   Commits (parts of) the current state of the working copy into the
   repository.

Example

   The working copy is /etc , and it is set up and committed already.
   Then /etc/hosts and /etc/inittab got modified. Since these are
   non-related changes, you'd like them to be in separate commits.

   So you simply run these commands:
   fsvs commit -m "Added some host" /etc/hosts
   fsvs commit -m "Tweaked default runlevel" /etc/inittab

   If the current directory is /etc you could even drop the /etc/ in
   front, and use just the filenames.

   Please see status for explanations on -v and -C .
   For advanced backup usage see also the commit-pipe property".

cp

   fsvs cp [-r rev] SRC DEST
   fsvs cp dump
   fsvs cp load

   The copy command marks DEST as a copy of SRC at revision rev, so that
   on the next commit of DEST the corresponding source path is sent as
   copy source.

   The default value for rev is BASE, ie. the revision the SRC (locally)
   is at.

   Please note that this command works always on a directory structure -
   if you say to copy a directory, the whole structure is marked as copy.
   That means that if some entries below the copy are missing, they are
   reported as removed from the copy on the next commit.
   (Of course it is possible to mark files as copied, too; non-recursive
   copies are not possible, but can be emulated by having parts of the
   destination tree removed.)

   Note
          TODO: There will be differences in the exact usage - copy will
          try to run the cp command, whereas copied will just remember the
          relation.

   If this command are used without parameters, the currently defined
   relations are printed; please keep in mind that the key is the
   destination name, ie. the 2nd line of each pair!

   The input format for load is newline-separated - first a SRC line,
   followed by a DEST line, then an line with just a dot ( ".") as
   delimiter. If you've got filenames with newlines or other special
   characters, you have to give the paths as arguments.

   Internally the paths are stored relative to the working copy base
   directory, and they're printed that way, too.

   Later definitions are appended to the internal database; to undo
   mistakes, use the uncopy action.

   Note
          Important: User-defined properties like fsvs:commit-pipe are not
          copied to the destinations, because of space/time issues
          (traversing through entire subtrees, copying a lot of
          property-files) and because it's not sure that this is really
          wanted. TODO: option for copying properties?

   Todo:
          -0 like for xargs?

   Todo:
          Are different revision numbers for load necessary? Should dump
          print the source revision number?

   Todo:
          Copying from URLs means update from there

   Note
          As subversion currently treats a rename as copy+delete, the mv
          command is an alias to cp.

   If you have a need to give the filenames dump or load as first
   parameter for copyfrom relations, give some path, too, as in "./dump".

   Note
          The source is internally stored as URL with revision number, so
          that operations like these

          $ fsvs cp a b

          $ rm a/1

          $ fsvs ci a

          $ fsvs ci b
          work - FSVS sends the old (too recent!) revision number as
          source, and so the local filelist stays consistent with the
          repository.
          But it is not implemented (yet) to give an URL as copyfrom
          source directly - we'd have to fetch a list of entries (and
          possibly the data!) from the repository.

   Todo:
          Filter for dump (patterns?).

copyfrom-detect

   fsvs copyfrom-detect [paths...]

   This command tells FSVS to look through the new entries, and see
   whether it can find some that seem to be copied from others already
   known.
   It will output a list with source and destination path and why it could
   match.

   This is just for information purposes and doesn't change any FSVS
   state, (TODO: unless some option/parameter is set).

   The list format is on purpose incompatible with the load syntax, as the
   best match normally has to be taken manually.

   Todo:
          some parameter that just prints the "best" match, and outputs
          the correct format.

   If verbose is used, an additional value giving the percentage of
   matching blocks, and the count of possibly copied entries is printed.

   Example:
   $ fsvs copyfrom-list -v
   newfile1
   md5:oldfileA
   newfile2
   md5:oldfileB
   md5:oldfileC
   md5:oldfileD
   newfile3
   inode:oldfileI
   manber=82.6:oldfileF
   manber=74.2:oldfileG
   manber=53.3:oldfileH
   ...
   3 copyfrom relations found.

   The abbreviations are:
   md5

   The MD5 of the new file is identical to that of one or more already
   committed files; there is no percentage.

   inode

   The device/inode number is identical to the given known entry; this
   could mean that the old entry has been renamed or hardlinked. Note: Not
   all filesystems have persistent inode numbers (eg. NFS) - so depending
   on your filesystems this might not be a good indicator!

   name

   The entry has the same name as another entry.

   manber

   Analysing files of similar size shows some percentage of
   (variable-sized) common blocks (ignoring the order of the blocks).

   dirlist

   The new directory has similar files to the old directory.
   The percentage is (number_of_common_entries)/(files_in_dir1 +
   files_in_dir2 - number_of_common_entries).

   Note
          manber matching is not implemented yet.
          If too many possible matches for an entry are found, not all are
          printed; only an indicator ... is shown at the end.

uncp

   fsvs uncopy DEST [DEST ...]

   The uncopy command removes a copyfrom mark from the destination entry.
   This will make the entry unknown again, and reported as New on the next
   invocations.

   Only the base of a copy can be un-copied; if a directory structure was
   copied, and the given entry is just implicitly copied, this command
   will return an error.

   This is not folded in revert, because it's not clear whether revert on
   copied, changed entries should restore the original copyfrom data or
   remove the copy attribute; by using another command this is no longer
   ambiguous.

   Example:
   $ fsvs copy SourceFile DestFile
   # Whoops, was wrong!
   $ fsvs uncopy DestFile

diff

   fsvs diff [-v] [-r rev[:rev2]] [-R] PATH [PATH...]

   This command gives you diffs between local and repository files.

   With -v the meta-data is additionally printed, and changes shown.

   If you don't give the revision arguments, you get a diff of the base
   revision in the repository (the last commit) against your current local
   file. With one revision, you diff this repository version against your
   local file. With both revisions given, the difference between these
   repository versions is calculated.

   You'll need the diff program, as the files are simply passed as
   parameters to it.

   The default is to do non-recursive diffs; so fsvs diff . will output
   the changes in all files in the current directory and below.

   The output for special files is the diff of the internal subversion
   storage, which includes the type of the special file, but no newline at
   the end of the line (which diff complains about).

   For entries marked as copy the diff against the (clean) source entry is
   printed.

   Please see also Options relating to the "diff" action and Using
   colordiff.

   Todo:
          Two revisions diff is buggy in that it (currently) always
          fetches the full trees from the repository; this is not only a
          performance degradation, but you'll see more changed entries
          than you want (like changes A to B to A). This will be fixed.

export

   fsvs export REPOS_URL [-r rev]

   If you want to export a directory from your repository without storing
   any FSVS-related data you can use this command.

   This restores all meta-data - owner, group, access mask and
   modification time; its primary use is for data recovery.

   The data gets written (in the correct directory structure) below the
   current working directory; if entries already exist, the export will
   stop, so this should be an empty directory.

help

   help [command]

   This command shows general or specific help (for the given command). A
   similar function is available by using -h or -? after a command.

groups

   fsvs groups dump|load
   fsvs groups [prepend|append|at=n] group-definition [group-def ...]
   fsvs ignore [prepend|append|at=n] pattern [pattern ...]
   fsvs groups test [-v|-q] [pattern ...]

   This command adds patterns to the end of the pattern list, or, with
   prepend, puts them at the beginning of the list. With at=x the patterns
   are inserted at the position x , counting from 0.

   The difference between groups and ignore is that groups requires a
   group name, whereas the latter just assumes the default group ignore.

   For the specification please see the related documentation .

   fsvs dump prints the patterns to STDOUT . If there are special
   characters like CR or LF embedded in the pattern without encoding (like
   \r or \n), the output will be garbled.

   The patterns may include * and ? as wildcards in one directory level,
   or ** for arbitrary strings.

   These patterns are only matched against new (not yet known) files;
   entries that are already versioned are not invalidated.
   If the given path matches a new directory, entries below aren't found,
   either; but if this directory or entries below are already versioned,
   the pattern doesn't work, as the match is restricted to the directory.

   So:
   fsvs ignore ./tmp

   ignores the directory tmp; but if it has already been committed,
   existing entries would have to be unmarked with fsvs unversion.
   Normally it's better to use
   fsvs ignore ./tmp/**

   as that takes the directory itself (which might be needed after restore
   as a mount point anyway), but ignore all entries below.
   Currently this has the drawback that mtime changes will be reported and
   committed; this is not the case if the whole directory is ignored.

   Examples:
   fsvs group group:unreadable,mode:4:0
   fsvs group 'group:secrets,/etc/*shadow'
   fsvs ignore /proc
   fsvs ignore /dev/pts
   fsvs ignore './var/log/*-*'
   fsvs ignore './**~'
   fsvs ignore './**/*.bak'
   fsvs ignore prepend 'take,./**.txt'
   fsvs ignore append 'take,./**.svg'
   fsvs ignore at=1 './**.tmp'
   fsvs group dump
   fsvs group dump -v
   echo "./**.doc" | fsvs ignore load
   # Replaces the whole list

   Note
          Please take care that your wildcard patterns are not expanded by
          the shell!

Testing patterns

   To see more easily what different patterns do you can use the test
   subcommand. The following combinations are available:
     * fsvs groups test pattern\n Tests only the given pattern against all
       new entries in your working copy, and prints the matching paths.
       The pattern is not stored in the pattern list.
     * fsvs groups test
       Uses the already defined patterns on the new entries, and prints
       the group name, a tab, and the path.
       With -v you can see the matching pattern in the middle column, too.

   By using -q you can avoid getting the whole list; this makes sense if
   you use the group_stats option at the same time.

rign

   fsvs rel-ignore [prepend|append|at=n] path-spec [path-spec ...]
   fsvs ri [prepend|append|at=n] path-spec [path-spec ...]

   If you keep the same repository data at more than one working copy on
   the same machine, it will be stored in different paths - and that makes
   absolute ignore patterns infeasible. But relative ignore patterns are
   anchored at the beginning of the WC root - which is a bit tiring to
   type if you're deep in your WC hierarchy and want to ignore some files.

   To make that easier you can use the rel-ignore (abbreviated as ri)
   command; this converts all given path-specifications (which may include
   wildcards as per the shell pattern specification above) to WC-relative
   values before storing them.

   Example for /etc as working copy root:
   fsvs rel-ignore '/etc/X11/xorg.conf.*'
   cd /etc/X11
   fsvs rel-ignore 'xorg.conf.*'

   Both commands would store the pattern "./X11/xorg.conf.*".

   Note
          This works only for shell patterns.

   For more details about ignoring files please see the ignore command and
   Specification of groups and patterns.

info

   fsvs info [-R [-R]] [PATH...]

   Use this command to show information regarding one or more entries in
   your working copy.
   You can use -v to obtain slightly more information.

   This may sometimes be helpful for locating bugs, or to obtain the URL
   and revision a working copy is currently at.

   Example:
   $ fsvs info
   URL: file:
   .... 200 .
   Type: directory
   Status: 0x0
   Flags: 0x100000
   Dev: 0
   Inode: 24521
   Mode: 040755
   UID/GID: 1000/1000
   MTime: Thu Aug 17 16:34:24 2006
   CTime: Thu Aug 17 16:34:24 2006
   Revision: 4
   Size: 200

   The default is to print information about the given entry only. With a
   single -R you'll get this data about all entries of a given directory;
   with another -R you'll get the whole (sub-)tree.

log

   fsvs log [-v] [-r rev1[:rev2]] [-u name] [path]

   This command views the revision log information associated with the
   given path at its topmost URL, or, if none is given, the highest
   priority URL.

   The optional rev1 and rev2 can be used to restrict the revisions that
   are shown; if no values are given, the logs are given starting from
   HEAD downwards, and then a limit on the number of revisions is applied
   (but see the limit option).

   If you use the -v -option, you get the files changed in each revision
   printed, too.

   There is an option controlling the output format; see the log_output
   option.

   Optionally the name of an URL can be given after -u; then the log of
   this URL, instead of the topmost one, is shown.

   TODOs:
     * –stop-on-copy
     * Show revision for all URLs associated with a working copy? In which
       order?

prop-get

   fsvs prop-get PROPERTY-NAME PATH...

   Prints the data of the given property to STDOUT.

   Note
          Be careful! This command will dump the property as it is, ie.
          with any special characters! If there are escape sequences or
          binary data in the property, your terminal might get messed up!
          If you want a safe way to look at the properties, use prop-list
          with the -v parameter.

prop-set

   fsvs prop-set [-u URLNAME] PROPERTY-NAME VALUE PATH...

   This command sets an arbitrary property value for the given path(s).

   Note
          Some property prefixes are reserved; currently everything
          starting with svn: throws a (fatal) warning, and fsvs: is
          already used, too. See Special property names.

   If you're using a multi-URL setup, and the entry you'd like to work on
   should be pinned to a specific URL, you can use the -u parameter; this
   is like the add command, see there for more details.

prop-del

   fsvs prop-del PROPERTY-NAME PATH...

   This command removes a property for the given path(s).

   See also prop-set.

prop-list

   fsvs prop-list [-v] PATH...

   Lists the names of all properties for the given entry.
   With -v, the value is printed as well; special characters will be
   translated, as arbitrary binary sequences could interfere with your
   terminal settings.

   If you need raw output, post a patch for –raw, or write a loop with
   prop-get.

remote-status

   fsvs remote-status PATH [-r rev]

   This command looks into the repository and tells you which files would
   get changed on an update - it's a dry-run for update .

   Per default it compares to HEAD, but you can choose another revision
   with the -r parameter.

   Please see the update documentation for details regarding multi-URL
   usage.

resolve

   fsvs resolve PATH [PATH...]

   When FSVS tries to update local files which have been changed, a
   conflict might occur. (For various ways of handling these please see
   the conflict option.)

   This command lets you mark such conflicts as resolved.

revert

   fsvs revert [-rRev] [-R] PATH [PATH...]

   This command undoes local modifications:
     * An entry that is marked to be unversioned gets this flag removed.
     * For a already versioned entry (existing in the repository) the
       local entry is replaced with its repository version, and its status
       and flags are cleared.
     * An entry that is a modified copy destination gets reverted to the
       copy source data.
     * Manually added entries are changed back to "N"ew.

   Please note that implicitly copied entries, ie. entries that are marked
   as copied because some parent directory is the base of a copy, can not
   be un-copied; they can only be reverted to their original (copied-from)
   data, or removed.

   If you want to undo a copy operation, please see the uncopy command.

   See also HOWTO: Understand the entries' statii.

   If a directory is given on the command line all versioned entries in
   this directory are reverted to the old state; this behaviour can be
   modified with -R/-N, or see below.

   The reverted entries are printed, along with the status they had before
   the revert (because the new status is per definition unchanged).

   If a revision is given, the entries' data is taken from this revision;
   furthermore, the new status of that entry is shown.

   Note
          Please note that mixed revision working copies are not (yet)
          possible; the BASE revision is not changed, and a simple revert
          without a revision arguments gives you that.
          By giving a revision parameter you can just choose to get the
          text from a different revision.

Difference to update

   If something doesn't work as it should in the installation you can
   revert entries until you are satisfied, and directly commit the new
   state.

   In contrast, if you update to an older version, you
     * cannot choose single entries (no mixed revision working copies
       yet),
     * and you cannot commit the old version with changes, as the
       "skipped" (later) changes will create conflicts in the repository.

Currently only known entries are handled.

   If you need a switch (like –delete in rsync(1) ) to remove unknown
   (new, not yet versioned) entries, to get the directory in the exact
   state it is in the repository, please tell the dev@ mailing list.

   Todo:
          Another limitation is that just-deleted just-committed entries
          cannot be fetched via revert, as FSVS no longer knows about
          them.
          TODO: If a revision is given, take a look there, and ignore the
          local data?
          As a workaround you could use the cat and/or checkout commands
          to fetch repository-only data.

Removed directory structures

   If a path is specified whose parent is missing, fsvs complains.
   We plan to provide a switch (probably -p), which would create (a
   sparse) tree up to this entry.

Recursive behaviour

   When the user specifies a non-directory entry (file, device, symlink),
   this entry is reverted to the old state.

   If the user specifies a directory entry, these definitions should
   apply:
   command line switch                        result
   -N                  this directory only (meta-data),
   none                this directory, and direct children of the directory,
   -R                  this directory, and the complete tree below.

Working with copied entries

   If an entry is marked as copied from another entry (and not
   committed!), a revert will fetch the original copyfrom source. To undo
   the copy setting use the uncopy command.

status

   fsvs status [-C [-C]] [-v] [-f filter] [PATHs...]

   This command shows the entries that have been changed locally since the
   last commit.

   The most important output formats are:
     * A status columns of four (or, with -v , six) characters. There are
       either flags or a "." printed, so that it's easily parsed by
       scripts – the number of columns is only changed by -q, -v –
       verbose/quiet.
     * The size of the entry, in bytes, or "dir" for a directory, or "dev"
       for a device.
     * The path and name of the entry, formatted by the path option.

   Normally only changed entries are printed; with -v all are printed, but
   see the filter option for more details.

   The status column can show the following flags:
     * 'D' and 'N' are used for deleted and new entries.
     * 'd' and 'n' are used for entries which are to be unversioned or
       added on the next commit; the characters were chosen as little
       delete (only in the repository, not removed locally) and little new
       (although ignored). See add and unversion.
       If such an entry does not exist, it is marked with an "!" in the
       last column – because it has been manually marked, and so the
       removal is unexpected.
     * A changed type (character device to symlink, file to directory
       etc.) is given as 'R' (replaced), ie. as removed and newly added.
     * If the entry has been modified, the change is shown as 'C'.
       If the modification or status change timestamps (mtime, ctime) are
       changed, but the size is still the same, the entry is marked as
       possibly changed (a question mark '?' in the last column) - but see
       change detection for details.
     * A 'x' signifies a conflict.
     * The meta-data flag 'm' shows meta-data changes like properties,
       modification timestamp and/or the rights (owner, group, mode);
       depending on the -v/-q command line parameters, it may be split
       into 'P' (properties), 't' (time) and 'p' (permissions).
       If 'P' is shown for the non-verbose case, it means only property
       changes, ie. the entries filesystem meta-data is unchanged.
     * A '+' is printed for files with a copy-from history; to see the URL
       of the copyfrom source, see the verbose option.

   Here's a table with the characters and their positions:
*   Without -v    With -v
*     ....         ......
*     NmC?         NtpPC?
*     DPx!         D   x!
*     R  +         R    +
*     d            d
*     n            n
*

   Furthermore please take a look at the stat_color option, and for more
   information about displayed data the verbose option.

sync-repos

   fsvs sync-repos [-r rev] [working copy base]

   This command loads the file list afresh from the repository.
   A following commit will send all differences and make the repository
   data identical to the local.

   This is normally not needed; the only use cases are
     * debugging and
     * recovering from data loss in the $FSVS_WAA area.

   It might be of use if you want to backup two similar machines. Then you
   could commit one machine into a subdirectory of your repository, make a
   copy of that directory for another machine, and sync this other
   directory on the other machine.

   A commit then will transfer only changed files; so if the two machines
   share 2GB of binaries ( /usr , /bin , /lib , ...) then these 2GB are
   still shared in the repository, although over time they will deviate
   (as both committing machines know nothing of the other path with
   identical files).

   This kind of backup could be substituted by two or more levels of
   repository paths, which get overlaid in a defined priority. So the base
   directory, which all machines derive from, will be committed from one
   machine, and it's no longer necessary for all machines to send
   identical files into the repository.

   The revision argument should only ever be used for debugging; if you
   fetch a filelist for a revision, and then commit against later
   revisions, problems are bound to occur.

   Note
          There's issue 2286 in subversion which describes sharing
          identical files in the repository in unrelated paths. By using
          this relaxes the storage needs; but the network transfers would
          still be much larger than with the overlaid paths.

update

   fsvs update [-r rev] [working copy base]
   fsvs update [-u url@rev ...] [working copy base]

   This command does an update on the current working copy; per default
   for all defined URLs, but you can restrict that via -u.

   It first reads all filelist changes from the repositories, overlays
   them (so that only the highest-priority entries are used), and then
   fetches all necessary changes.

Updating to zero

   If you start an update with a target revision of zero, the entries
   belonging to that URL will be removed from your working copy, and the
   URL deleted from your URL list.
   This is a convenient way to replace an URL with another.

   Note
          As FSVS has no full mixed revision support yet, it doesn't know
          whether under the removed entry is a lower-priority one with the
          same path, which should get visible now.
          Directories get changed to the highest priority URL that has an
          entry below (which might be hidden!).

   Because of this you're advised to either use that only for completely
   distinct working copies, or do a sync-repos (and possibly one or more
   revert calls) after the update.

urls

   fsvs urls URL [URLs...]
   fsvs urls dump
   fsvs urls load

   Initializes a working copy administrative area and connects the current
   working directory to REPOS_URL. All commits and updates will be done to
   this directory and against the given URL.

   Example:
   fsvs urls http://svn/repos/installation/machine-1/trunk

   For a format definition of the URLs please see the chapter Format of
   URLs.

   Note
          If there are already URLs defined, and you use that command
          later again, please note that as of 1.0.18 the older URLs are
          not overwritten as before, but that the new URLs are appended to
          the given list! If you want to start afresh, use something like

          true | fsvs urls load

Loading URLs

   You can load a list of URLs from STDIN; use the load subcommand for
   that.

   Example:
   ( echo 'N:local,prio:10,http://svn/repos/install/machine-1/trunk' ;
   echo 'P:50,name:common,http://svn/repos/install/common/trunk' ) |
   fsvs urls load

   Empty lines are ignored.

Dumping the defined URLs

   To see which URLs are in use for the current WC, you can use dump.

   As an optional parameter you can give a format statement:
   p priority
   n name
   r current revision
   t target revision
   R readonly-flag
   u URL
   I internal number for this URL

   Note
          That's not a real printf()-format; only these and a few \
          sequences are recognized.

   Example:
   fsvs urls dump " %u %n:%p\\n"
   http://svn/repos/installation/machine-1/trunk local:10
   http://svn/repos/installation/common/trunk common:50

   The default format is "name:%n,prio:%p,target:%t,ro:%r,%u\\n"; for a
   more readable version you can use -v.

Loading URLs

   You can change the various parameters of the defined URLs like this:
   # Define an URL
   fsvs urls name:url1,target:77,readonly:1,http://anything/...
   # Change values
   fsvs urls name:url1,target:HEAD
   fsvs urls readonly:0,http://anything/...
   fsvs urls name:url1,prio:88,target:32

   Note
          FSVS as yet doesn't store the whole tree structures of all URLs.
          So if you change the priority of an URL, and re-mix the
          directory trees that way, you'll need a sync-repos and some
          revert commands.
          I'd suggest to avoid this, until FSVS does handle that case
          better.

   estat::md5
   md5_digest_t md5
   MD5-hash of the repository version.
   Definition: global.h:336

   filename
   static char * filename
   Definition: update.c:90

   estat::url
   struct url_t * url
   The URL this entry is from.
   Definition: global.h:318

   estat::name
   char * name
   Name of this entry.
   Definition: global.h:303

   status
   status
   Definition: cache.h:143