Browsing Spanish translation

1435.

Set the value of a property on files, dirs, or revisions.
usage: 1. propset PROPNAME PROPVAL PATH...
2. propset PROPNAME --revprop -r REV PROPVAL [TARGET]

1. Creates a versioned, local propchange in working copy.
2. Creates an unversioned, remote propchange on repos revision.
TARGET only determines which repository to access.

The value may be provided with the --file option instead of PROPVAL.

Note: svn recognizes the following special versioned properties
but will store any arbitrary properties set:
svn:ignore - A newline separated list of file patterns to ignore.
svn:keywords - Keywords to be expanded. Valid keywords are:
URL, HeadURL - The URL for the head version of the object.
Author, LastChangedBy - The last person to modify the file.
Date, LastChangedDate - The date/time the object was last modified.
Rev, Revision, - The last revision the object changed.
LastChangedRevision
Id - A compressed summary of the previous
4 keywords.
svn:executable - If present, make the file executable. Use
'svn propdel svn:executable PATH...' to clear.
svn:eol-style - One of 'native', 'LF', 'CR', 'CRLF'.
svn:mime-type - The mimetype of the file. Used to determine
whether to merge the file, and how to serve it from Apache.
A mimetype beginning with 'text/' (or an absent mimetype) is
treated as text. Anything else is treated as binary.
svn:externals - A newline separated list of module specifiers,
each of which consists of a relative directory path, optional
revision flags and an URL. The ordering of the three elements
implements different behavior. Subversion 1.4 and earlier only
support the following formats and the URLs cannot have peg
revisions:
foo http://example.com/repos/zig
foo/bar -r 1234 http://example.com/repos/zag
Subversion 1.5 and greater support the above formats and the
following formats where the URLs may have peg revisions:
http://example.com/repos/zig foo
-r 1234 http://example.com/repos/zig foo/bar
Relative URLs are supported in Subversion 1.5 and greater for
all above formats and are indicated by starting the URL with one
of the following strings
../ to the parent directory of the extracted external
^/ to the repository root
// to the scheme
/ to the server root
The ambiguous format 'relative_path relative_path' is taken as
'relative_url relative_path' with peg revision support.
svn:needs-lock - If present, indicates that the file should be locked
before it is modified. Makes the working copy file read-only
when it is not locked. Use 'svn propdel svn:needs-lock PATH...'
to clear.

The svn:keywords, svn:executable, svn:eol-style, svn:mime-type and
svn:needs-lock properties cannot be set on a directory. A non-recursive
attempt will fail, and a recursive attempt will set the property
only on the file children of the directory.

1442.

Update the working copy to a different URL.
usage: 1. switch URL[@PEGREV] [PATH]
2. switch --relocate FROM TO [PATH...]

1. Update the working copy to mirror a new URL within the repository.
This behaviour is similar to 'svn update', and is the way to
move a working copy to a branch or tag within the same repository.
If specified, PEGREV determines in which revision the target is first
looked up.

If --force is used, unversioned obstructing paths in the working
copy do not automatically cause a failure if the switch attempts to
add the same path. If the obstructing path is the same type (file
or directory) as the corresponding path in the repository it becomes
versioned but its contents are left 'as-is' in the working copy.
This means that an obstructing directory's unversioned children may
also obstruct and become versioned. For files, any content differences
between the obstruction and the repository are treated like a local
modification to the working copy. All properties from the repository
are applied to the obstructing path.

Use the --set-depth option to set a new working copy depth on the
targets of this operation. Currently, the depth of a working copy
directory can only be increased (telescoped more deeply); you cannot
make a directory more shallow.

2. Rewrite working copy URL metadata to reflect a syntactic change only.
This is used when repository's root URL changes (such as a scheme
or hostname change) but your working copy still reflects the same
directory within the same repository.

1444.

Bring changes from the repository into the working copy.
usage: update [PATH...]

If no revision given, bring working copy up-to-date with HEAD rev.
Else synchronize working copy to revision given by -r.

For each updated item a line will start with a character reporting the
action taken. These characters have the following meaning:

A Added
D Deleted
U Updated
C Conflict
G Merged
E Existed

A character in the first column signifies an update to the actual file,
while updates to the file's properties are shown in the second column.
A 'B' in the third column signifies that the lock for the file has
been broken or stolen.

If --force is used, unversioned obstructing paths in the working
copy do not automatically cause a failure if the update attempts to
add the same path. If the obstructing path is the same type (file
or directory) as the corresponding path in the repository it becomes
versioned but its contents are left 'as-is' in the working copy.
This means that an obstructing directory's unversioned children may
also obstruct and become versioned. For files, any content differences
between the obstruction and the repository are treated like a local
modification to the working copy. All properties from the repository
are applied to the obstructing path. Obstructing paths are reported
in the first column with code 'E'.

Use the --set-depth option to set a new working copy depth on the
targets of this operation. Currently, the depth of a working copy
directory can only be increased (telescoped more deeply); you cannot
make a directory more shallow.

1620.

usage: svnadmin upgrade REPOS_PATH

Upgrade the repository located at REPOS_PATH to the latest supported
schema version.

This functionality is provided as a convenience for repository
administrators who wish to make use of new Subversion functionality
without having to undertake a potentially costly full repository dump
and load operation. As such, the upgrade performs only the minimum
amount of work needed to accomplish this while still maintaining the
integrity of the repository. It does not guarantee the most optimized
repository state as a dump and subsequent load would.

1649.

Upgrade of this repository's underlying versioned filesystem is not supported; consider dumping and loading the data elsewhere

1650.

Upgrade of this repository is not supported; consider dumping and loading the data elsewhere

1662.

No valid revision range 'start' in filtered stream

1663.

No valid revision range 'end' in filtered stream

1779.

Unknown revprop word '%s' in log command