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.
fsvs command [options] [args]
The following commands are understood by FSVS:
- Define working copy base directories by their URL(s)
- Get a list of changed entries
- Display detailed information about single entries
- Fetch the log messages from the repository
- Get differences between files (local and remote)
- Ask FSVS about probably copied/moved/renamed entries; see
- ignore and
- Define ignore patterns
- Remove entries from versioning
- Add entries that would be ignored
- cp, mv
- Tell FSVS that entries were copied
- Send changed data to the repository
- Get updates from the repository
- Fetch some part of the repository, and register it as
- Get a file from the directory
- revert and
- Undo local changes and entry markings
- Ask what an update would bring
- Set user-defined properties
- Ask value of user-defined properties
- Get a list of user-defined properties
- Fetch some part of the repository
- Drop local information about the entries, and fetch the
current list from the repository.
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
-V makes FSVS print the version and a copyright notice, and exit.
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
please see the options list.
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.
-v/-q set/clear verbosity flags, and so give more/less output.
Please see the verbose option
for more details.
-C chooses to use more change detection checks; please see the change_check
for more details.
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.
Please see Change detection
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
If you use -v, it's used as a any internally.
If you use the string none, it resets the bitmask to no
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.
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
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
- stop to abort the program,
- ignore to simply ignore this situation, or
- count to just count the number of occurrences.
matches more than one situation, all of them are set;
eg. for meta=ignore
all of meta-mtime
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
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
This warning is issued if a info
action is executed,
but no URLs have been defined yet.
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.
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
This way you can make the errors non-fatal.
If you get another error than EPERM in
the situation above, you might find these useful.
If you specify some revision number on a revert
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.
It is normally not allowed to set a property with the
action with a name matching some reserved prefixes.
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.
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.
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
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
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).
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
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.
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
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.
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.
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
Then you do a
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
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
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.
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
Look at sync-repos
This command delays execution until time has passed at least to the next second
after writing the data files used by FSVS ( dir
This command is for use in scripts; where previously the delay
was used, this can be substituted by the given command followed by the delay
The advantage against the delay
option is that read-only commands can be
used in the meantime.
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
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
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.
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
and the urls
Furthermore you might be interested in Using an alternate root directory
and Recovery for a non-booting system
fsvs commit [-m 'message'|-F filename] [-v] [-C [-C]] [PATH [PATH ...]]
Commits (parts of) the current state of the working copy into the repository.
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
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
- if you say to copy a directory, the whole
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
TODO: There will be differences in the exact
usage - copy will try to run the cp command, whereas copied will just remember
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
User-defined properties like
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.
option for copying properties?
As subversion currently treats a rename as copy+delete, the mv
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'.
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
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.
is used, an additional value giving the percentage of
matching blocks, and the count of possibly copied entries is printed.
$ fsvs copyfrom-list -v
3 copyfrom relations found.
The abbreviations are: md5
of the new file is identical
to that of one or more already committed files; there is no percentage.
number is identical to the given known
entry; this could mean that the old entry has been renamed or hardlinked.
Not all filesystems have persistent inode numbers (eg. NFS) - so
depending on your filesystems this might not be a good indicator!
The entry has the same name as another entry.
Analysing files of similar size shows some percentage of
(variable-sized) common blocks
(ignoring the order of the blocks).
The new directory has similar files to the old directory.
The percentage is (number_of_common_entries)/(files_in_dir1 + files_in_dir2 -
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.
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
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
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.
$ fsvs copy SourceFile DestFile
# Whoops, was wrong!
$ fsvs uncopy DestFile
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
You'll need the diff program, as the files are simply passed as parameters to
The default is to do non-recursive diffs; so fsvs diff . will output the
changes in all files in the current directory
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
Please see also Options relating to the 'diff' action
fsvs export REPOS_URL [-r rev]
If you want to export a directory from your repository without
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.
This command shows general or specific help
(for the given command). A
similar function is available by using -h or -? after a command.
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
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
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.
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
Currently this has the drawback that mtime changes will be reported and
committed; this is not the case if the whole directory is ignored.
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
Please take care that your wildcard patterns
are not expanded by the shell!
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
- 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
option at the same time.
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
Example for /etc as working copy root:
fsvs rel-ignore '/etc/X11/xorg.conf.*'
fsvs rel-ignore 'xorg.conf.*'
Both commands would store the pattern './X11/xorg.conf.*'.
This works only for shell
For more details about ignoring files please see the ignore
Specification of groups and patterns
fsvs info [-R [-R]] [PATH...]
Use this command to show information regarding one or more entries in your
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.
$ fsvs info
.... 200 .
MTime: Thu Aug 17 16:34:24 2006
CTime: Thu Aug 17 16:34:24 2006
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.
fsvs log [-v] [-r rev1[:rev2]] [-u name] [path]
This command views the revision log information associated with the given
at its topmost URL, or, if none is given, the highest priority
The optional rev1
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
If you use the -v
-option, you get the files changed in each revision
There is an option controlling the output format; see the log_output
Optionally the name of an URL can be given after -u; then the log of this URL,
instead of the topmost one, is shown.
- Show revision for all URLs associated with a working
copy? In which order?
fsvs prop-get PROPERTY-NAME PATH...
Prints the data of the given property to STDOUT.
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
fsvs prop-set [-u URLNAME] PROPERTY-NAME VALUE PATH...
This command sets an arbitrary property value for the given path(s).
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
command, see there for more details.
fsvs prop-del PROPERTY-NAME PATH...
This command removes a property for the given path(s).
See also prop-set
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
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
Please see the update
documentation for details regarding multi-URL
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
This command lets you mark such conflicts as resolved.
fsvs revert [-rRev] [-R] PATH [PATH...]
This command undoes local modifications:
- An entry that is marked to be unversioned gets this flag
- 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
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
un-copied; they can only be reverted to their original (copied-from) data, or
If you want to undo a copy operation, please see the uncopy
See also HOWTO: Understand the entries' statii
If a directory is given on the command line all versioned entries in this
are reverted to the old state; this behaviour can be modified
, or see below.
The reverted entries are printed, along with the status they had before
the revert (because the new status is per definition
If a revision is given, the entries' data is taken from this revision;
furthermore, the new
status of that entry is
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
If something doesn't work as it should in the installation you can revert
entries until you are satisfied, and directly commit
In contrast, if you update
to an older version, you
- cannot choose single entries (no mixed revision working
- and you cannot commit the old version with changes, as the
'skipped' (later) changes will create conflicts in the repository.
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.
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.
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.
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
fsvs status [-C [-C]] [-v] [-f filter] [PATHs...]
This command shows the entries that have been changed locally since the last
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 --
- 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
Normally only changed entries are printed; with -v all are printed, but see the
option for more details.
The status column can show the following flags:
- 'D' and 'N' are used for deleted and new
- '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
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
- A changed type (character device to symlink, file to
directory etc.) is given as 'R' (replaced), ie. as removed and newly
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
- 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
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
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
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
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.
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.
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
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
This is a convenient way to replace an URL with another.
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
calls) after the update.
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.
fsvs urls http://svn/repos/installation/machine-1/trunk
For a format definition of the URLs please see the chapter Format of
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
as before, but that the new URLs are appended
the given list! If you want to start afresh, use something like
true | fsvs urls load
You can load a list of URLs from STDIN; use the load subcommand for that.
( 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.
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
That's not a real printf()-format; only these
and a few \ sequences are recognized.
fsvs urls dump ' %u %n:%p\n'
The default format is 'name:%n,prio:%p,target:%t,ro:%r,%u\\n'; for a more
readable version you can use -v
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
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
Generated automatically by Doxygen for fsvs from the source code.