Provided by: fsvs_1.2.7-1build2_amd64 bug

NAME

       Commands and command line parameters -

       fsvs is a client for subversion repositories; it is designed for fast versioning of big
       directory trees.  fsvs is a client for subversion repositories; it is designed for fast
       versioning of big directory trees.

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 one 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?

           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.

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.

         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.

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  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.
   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
       switchresult -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.

Author

       Generated automatically by Doxygen for fsvs from the source code.