Browsing Bosnian translation

1666.

Default: '-u'. When Subversion is invoking an
external diff program, ARG is simply passed along
to the program. But when Subversion is using its
default internal diff implementation, or when
Subversion is displaying blame annotations, ARG
could be any of the following:
-u (--unified):
Output 3 lines of unified context.
-b (--ignore-space-change):
Ignore changes in the amount of white space.
-w (--ignore-all-space):
Ignore all white space.
--ignore-eol-style:
Ignore changes in EOL style.
-p (--show-c-function):
Show C function name in diff output.

1718.

Allow merge into mixed-revision working copy.
Use of this option is not recommended!
Please run 'svn update' instead.

1725.

Recursively clean up the working copy, removing locks, resuming
unfinished operations, etc.
usage: cleanup [WCPATH...]

1726.

Send changes from your working copy to the repository.
usage: commit [PATH...]

A log message must be provided, but it can be empty. If it is not
given by a --message or --file option, an editor will be started.
If any targets are (or contain) locked items, those will be
unlocked after a successful commit.

1727.

Duplicate something in working copy or repository, remembering
history.
usage: copy SRC[@REV]... DST

When copying multiple sources, they will be added as children of DST,
which must be a directory.

SRC and DST can each be either a working copy (WC) path or URL:
WC -> WC: copy and schedule for addition (with history)
WC -> URL: immediately commit a copy of WC to URL
URL -> WC: check out URL into WC, schedule for addition
URL -> URL: complete server-side copy; used to branch and tag
All the SRCs must be of the same type.

WARNING: For compatibility with previous versions of Subversion,
copies performed using two working copy paths (WC -> WC) will not
contact the repository. As such, they may not, by default, be able
to propagate merge tracking information from the source of the copy
to the destination.

1729.

Display the differences between two revisions or paths.
usage: 1. diff [-c M | -r N[:M]] [TARGET[@REV]...]
2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \
[PATH...]
3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]

1. Display the changes made to TARGETs as they are seen in REV between
two revisions. TARGETs may be all working copy paths or all URLs.
If TARGETs are working copy paths, N defaults to BASE and M to the
working copy; if URLs, N must be specified and M defaults to HEAD.
The '-c M' option is equivalent to '-r N:M' where N = M-1.
Using '-c -M' does the reverse: '-r M:N' where N = M-1.

2. Display the differences between OLD-TGT as it was seen in OLDREV and
NEW-TGT as it was seen in NEWREV. PATHs, if given, are relative to
OLD-TGT and NEW-TGT and restrict the output to differences for those
paths. OLD-TGT and NEW-TGT may be working copy paths or URL[@REV].
NEW-TGT defaults to OLD-TGT if not specified. -r N makes OLDREV default
to N, -r N:M makes OLDREV default to N and NEWREV default to M.

3. Shorthand for 'svn diff --old=OLD-URL[@OLDREV] --new=NEW-URL[@NEWREV]'

Use just 'svn diff' to display local modifications in a working copy.

1733.

Display information about a local or remote item.
usage: info [TARGET[@REV]...]

Print information about each TARGET (default: '.').
TARGET may be either a working-copy path or URL. If specified, REV
determines in which revision the target is first looked up.

1739.

Show the log messages for a set of revision(s) and/or path(s).
usage: 1. log [PATH][@REV]
2. log URL[@REV] [PATH...]

1. Print the log messages for the URL corresponding to PATH
(default: '.'). If specified, REV is the revision in which the
URL is first looked up, and the default revision range is REV:1.
If REV is not specified, the default revision range is BASE:1,
since the URL might not exist in the HEAD revision.

2. Print the log messages for the PATHs (default: '.') under URL.
If specified, REV is the revision in which the URL is first
looked up, and the default revision range is REV:1; otherwise,
the URL is looked up in HEAD, and the default revision range is
HEAD:1.

Multiple '-c' or '-r' options may be specified (but not a
combination of '-c' and '-r' options), and mixing of forward and
reverse ranges is allowed.

With -v, also print all affected paths with each log message.
With -q, don't print the log message body itself (note that this is
compatible with -v).

Each log message is printed just once, even if more than one of the
affected paths for that revision were explicitly requested. Logs
follow copy history by default. Use --stop-on-copy to disable this
behavior, which can be useful for determining branchpoints.

The --depth option is only valid in combination with the --diff option
and limits the scope of the displayed diff to the specified depth.

Examples:
svn log
svn log foo.c
svn log bar.c@42
svn log http://www.example.com/repo/project/foo.c
svn log http://www.example.com/repo/project foo.c bar.c
svn log http://www.example.com/repo/project@50 foo.c bar.c

1742.

Merge changes into a working copy.
usage: 1. merge SOURCE[@REV] [TARGET_WCPATH]
(the 'sync' merge)
2. merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH]
(the 'cherry-pick' merge)
3. merge --reintegrate SOURCE[@REV] [TARGET_WCPATH]
(the 'reintegrate' merge)
4. merge SOURCE1[@N] SOURCE2[@M] [TARGET_WCPATH]
(the '2-URL' merge)

1. This form is called a 'sync' (or 'catch-up') merge:

svn merge SOURCE[@REV] [TARGET_WCPATH]

A sync merge is used to fetch all the latest changes made on a parent
branch. In other words, the target branch has originally been created
by copying the source branch, and any changes committed on the source
branch since branching are applied to the target branch. This uses
merge tracking to skip all those revisions that have already been
merged, so a sync merge can be repeated periodically to stay up-to-
date with the source branch.

SOURCE specifies the branch from where the changes will be pulled, and
TARGET_WCPATH specifies a working copy of the target branch to which
the changes will be applied. Normally SOURCE and TARGET_WCPATH should
each correspond to the root of a branch. (If you want to merge only a
subtree, then the subtree path must be included in both SOURCE and
TARGET_WCPATH; this is discouraged, to avoid subtree mergeinfo.)

SOURCE is usually a URL. The optional '@REV' specifies both the peg
revision of the URL and the latest revision that will be considered
for merging; if REV is not specified, the HEAD revision is assumed. If
SOURCE is a working copy path, the corresponding URL of the path is
used, and the default value of 'REV' is the base revision (usually the
revision last updated to).

TARGET_WCPATH is a working copy path; if omitted, '.' is assumed.

- Sync Merge Example -

A feature is being developed on a branch called 'feature', which has
originally been a copy of trunk. The feature branch has been regularly
synced with trunk to keep up with the changes made there. The previous
sync merges are not shown on this diagram, and the last of them was
done when HEAD was r100. Currently, HEAD is r200.

feature +------------------------o-----
/ ^
/ ............ |
/ . . /
trunk ------+------------L--------------R------
r100 r200

Subversion will locate all the changes on 'trunk' that have not yet
been merged into the 'feature' branch. In this case that is a single
range, r100:200. In the diagram above, L marks the left side
(trunk@100) and R marks the right side (trunk@200) of the merge. The
difference between L and R will be applied to the target working copy
path. In this case, the working copy is a clean checkout of the entire
'feature' branch.

To perform this sync merge, have a clean working copy of the feature
branch and run the following command in its top-level directory:

svn merge ^/trunk

Note that the merge is now only in your local working copy and still
needs to be committed to the repository so that it can be seen by
others. You can review the changes and you may have to resolve
conflicts before you commit the merge.


2. This form is called a 'cherry-pick' merge:

svn merge [-c M[,N...] | -r N:M ...] SOURCE[@REV] [TARGET_WCPATH]

A cherry-pick merge is used to merge specific revisions (or revision
ranges) from one branch to another. By default, this uses merge
tracking to automatically skip any revisions that have already been
merged to the target; you can use the --ignore-ancestry option to
disable such skipping.

SOURCE is usually a URL. The optional '@REV' specifies only the peg
revision of the URL and does not affect the merge range; if REV is not
specified, the HEAD revision is assumed. If SOURCE is a working copy
path, the corresponding URL of the path is used, and the default value
of 'REV' is the base revision (usually the revision last updated to).

TARGET_WCPATH is a working copy path; if omitted, '.' is assumed.

The revision ranges to be merged are specified by the '-r' and/or '-c'
options. '-r N:M' refers to the difference in the history of the
source branch between revisions N and M. You can use '-c M' to merge
single revisions: '-c M' is equivalent to '-r <M-1>:M'. Each such
difference is applied to TARGET_WCPATH.

If the mergeinfo in TARGET_WCPATH indicates that revisions within the
range were already merged, changes made in those revisions are not
merged again. If needed, the range is broken into multiple sub-ranges,
and each sub-range is merged separately.

A 'reverse range' can be used to undo changes. For example, when
source and target refer to the same branch, a previously committed
revision can be 'undone'. In a reverse range, N is greater than M in
'-r N:M', or the '-c' option is used with a negative number: '-c -M'
is equivalent to '-r M:<M-1>'.

Multiple '-c' and/or '-r' options may be specified and mixing of
forward and reverse ranges is allowed.

- Cherry-pick Merge Example -

A bug has been fixed on trunk in revision 50. This fix needs to
be merged from trunk onto the release branch.

1.x-release +-----------------------o-----
/ ^
/ |
/ |
trunk ------+--------------------------LR-----
r50

In the above diagram, L marks the left side (trunk@49) and R marks the
right side (trunk@50) of the merge. The difference between the left
and right side is applied to the target working copy path.

Note that the difference between revision 49 and 50 is exactly those
changes that were committed in revision 50, not including changes
committed in revision 49.

To perform the merge, have a clean working copy of the release branch
and run the following command in its top-level directory; remember
that the default target is '.':

svn merge -c50 ^/trunk

You can also cherry-pick several revisions and/or revision ranges:

svn merge -c50,54,60 -r65:68 ^/trunk


3. This form is called a 'reintegrate merge':

svn merge --reintegrate SOURCE[@REV] [TARGET_WCPATH]

In a reintegrate merge, an (e.g. feature) branch is merged back to its
originating branch. In other words, the source branch has originally
been created by copying the target branch, development has concluded
on the source branch and it should now be merged back into the target
branch.

SOURCE is the URL of a branch to be merged back. If REV is specified,
it is used as the peg revision for SOURCE; if REV is not specified,
the HEAD revision is assumed.

TARGET_WCPATH is a working copy of the branch the changes will be
applied to.

- Reintegrate Merge Example -

A feature has been developed on a branch called 'feature'. The feature
branch started as a copy of trunk@W. Work on the feature has completed
and it should be merged back into the trunk.

The feature branch was last synced with trunk up to revision X. So the
difference between trunk@X and feature@HEAD contains the complete set
of changes that implement the feature, and no other changes. These
changes are applied to trunk.

feature +--------------------------------R
/ . \
/ ............. \
/ . v
trunk ------+--------------------L------------------o
rW rX

In the diagram above, L marks the left side (trunk@X) and R marks the
right side (feature@HEAD) of the merge. The difference between the
left and right side is merged into trunk, the target.

To perform the merge, have a clean working copy of trunk and run the
following command in its top-level directory:

svn merge --reintegrate ^/feature

To prevent unnecessary merge conflicts, a reintegrate merge requires
that TARGET_WCPATH is not a mixed-revision working copy, has no local
modifications, and has no switched subtrees.

A reintegrate merge also requires that the source branch is coherently
synced with the target -- in the above example, this means that all
revisions between the branch point W and the last merged revision X
are merged to the feature branch, so that there are no unmerged
revisions in-between.

After the reintegrate merge, the feature branch cannot be synced to
the trunk again without merge conflicts. If further work must be done
on the feature branch, it should be deleted and then re-created.


4. This form is called a '2-URL merge':

svn merge SOURCE1[@N] SOURCE2[@M] [TARGET_WCPATH]

Two source URLs are specified, together with two revisions N and M.
The two sources are compared at the specified revisions, and the
difference is applied to TARGET_WCPATH, which is a path to a working
copy of another branch. The three branches involved can be completely
unrelated.

You should use this merge variant only if the other variants do not
apply to your situation, as this variant can be quite complex to
master.

If TARGET_WCPATH is omitted, a default value of '.' is assumed.
However, in the special case where both sources refer to a file node
with the same basename and a similarly named file is also found within
'.', the differences will be applied to that local file. The source
revisions default to HEAD if omitted.

The sources can also be specified as working copy paths, in which case
the URLs of the merge sources are derived from the working copies.

- 2-URL Merge Example -

Two features have been developed on separate branches called 'foo' and
'bar'. It has since become clear that 'bar' should be combined with
the 'foo' branch for further development before reintegration.

Although both feature branches originate from trunk, they are not
directly related -- one is not a direct copy of the other. A 2-URL
merge is necessary.

The 'bar' branch has been synced with trunk up to revision 500.
(If this revision number is not known, it can be located using the
'svn log' and/or 'svn mergeinfo' commands.)
The difference between trunk@500 and bar@HEAD contains the complete
set of changes related to feature 'bar', and no other changes. These
changes are applied to the 'foo' branch.

foo +-----------------------------------o
/ ^
/ /
/ r500 /
trunk ------+------+-----------------L---------> /
\ . /
\ ............ /
\ . /
bar +-----------------------------------R

In the diagram above, L marks the left side (trunk@500) and R marks
the right side (bar@HEAD) of the merge. The difference between the
left and right side is applied to the target working copy path, in
this case a working copy of the 'foo' branch.

To perform the merge, have a clean working copy of the 'foo' branch
and run the following command in its top-level directory:

svn merge ^/trunk@500 ^/bar

The exact changes applied by a 2-URL merge can be previewed with svn's
diff command, which is a good idea to verify if you do not have the
luxury of a clean working copy to merge to. In this case:

svn diff ^/trunk@500 ^/bar@HEAD


The following applies to all types of merges:

To prevent unnecessary merge conflicts, svn merge requires that
TARGET_WCPATH is not a mixed-revision working copy. Running 'svn update'
before starting a merge ensures that all items in the working copy are
based on the same revision.

If possible, you should have no local modifications in the merge's target
working copy prior to the merge, to keep things simpler. It will be
easier to revert the merge and to understand the branch's history.

Switched sub-paths should also be avoided during merging, as they may
cause incomplete merges and create subtree mergeinfo.

For each merged item a line will be printed with characters reporting the
action taken. These characters have the following meaning:

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

Characters in the first column report about the item itself.
Characters in the second column report about properties of the item.
A 'C' in the third column indicates a tree conflict, while a 'C' in
the first and second columns indicate textual conflicts in files
and in property values, respectively.

- Merge Tracking -

Subversion uses the svn:mergeinfo property to track merge history. This
property is considered at the start of a merge to determine what to merge
and it is updated at the conclusion of the merge to describe the merge
that took place. Mergeinfo is used only if the two sources are on the
same line of history -- if the first source is an ancestor of the second,
or vice-versa (i.e. if one has originally been created by copying the
other). This is verified and enforced when using sync merges and
reintegrate merges.

The --ignore-ancestry option prevents merge tracking and thus ignores
mergeinfo, neither considering it nor recording it.

- Merging from foreign repositories -

Subversion does support merging from foreign repositories.
While all merge source URLs must point to the same repository, the merge
target working copy may come from a different repository than the source.
However, there are some caveats. Most notably, copies made in the
merge source will be transformed into plain additions in the merge
target. Also, merge-tracking is not supported for merges from foreign
repositories.

1743.

Display merge-related information.
usage: mergeinfo SOURCE[@REV] [TARGET[@REV]]

Display information related to merges (or potential merges) between
SOURCE and TARGET (default: '.'). Display the type of information
specified by the --show-revs option. If --show-revs isn't passed,
it defaults to --show-revs='merged'.

The depth can be 'empty' or 'infinity'; the default is 'empty'.