Name

svk smerge — Automatically merge all changes between branches.

Synopsis

svk smerge DEPOTPATH [PATH]
svk smerge DEPOTPATH1 DEPOTPATH2
svk smerge --from [TARGET]
svk smerge --to [TARGET]

Description

The first form merges changes from the specified DEPOTPATH to the working copy specified by PATH or . if PATH is omitted.

The second form performs a direct in depot merge from DEPOTPATH1 to DEPOTPATH2.

The third form will merge changes from the closest copy anchor in the depot of the specified TARGET—which must be a depotpath that is a copy of something else, or a working copy who's depotpath is a copy of something. Directly in the depot to the source from which TARGET was copied. Essentially this pushes the changes since the last smerge on the specified branch to it's parent.

The fourth form will merge changes directly in the depot to the closest copy anchor in the depot specified by TARGET—which must be a depotpath that is a copy of something else, or a working copy who's depotpath is a copy of something, from the source of the original upstream copy. Essentially this pulls the parents changes since the last smerge into the specified branch.

Alternate Names

sm

Changes

Working copy if merging to a working copy. Depot if merging to a depotpath, and mirrored repository if the destination is a mirrored depotpath.

Accesses Depot

Yes

Accesses Mirrored Repository

Only if merging to a mirrored path.

Switches

--incremental (-I)
--log (-l)
--baseless (-B)
--base (-b) REV[@]
--sync (-s)
--to (-t)
--from (-f)
--verbatim
--no-ticket
--track-rename
--host HOST
--remoterev
--message (-m)
--file (-F)
--template
--encoding ENC
--patch (-P) NAME
--sign (-S)
--check-only (-C)
--direct

Examples

Let's say you have worked on a project locally in your svk depot until now, and you've decided it's time to publish your project and it's history to a remote Subversion repository. Furthermore let's assume you have already mirrored the repository in question and there are empty trunk tags and branches folders in the mirror. Let's say locally your project is at //project and the new mirror of the Subversion reository you wish to publish to is at //mirrors/project. To publish the entire history of you local project you would run:

$ svk smerge --baseless --incremental --verbatim //project //mirrors/project/trunk
Auto-merging (0, 4) /project to /mirrors/project/trunk (base /:0).
===> Auto-merging (0, 1) /project to /mirrors/project/trunk (base /:0).
Merging back to mirror source svn ssh://localhost/Users/sally/project-repo.
Empty merge.
===> Auto-merging (1, 2) /project to /mirrors/project/trunk (base /:0).
Merging back to mirror source svn ssh://localhost/Users/sally/project-repo.
A   README
New merge ticket: 8b976603-c150-4cc8-864b-160347647051:/project:2
Merge back committed as revision 2.
yncing svn ssh://localhost/Users/sally/project-repo
Retrieving log information from 2 to 2
Committed revision 7 from revision 2.
…

The --baseless switch makes the smerge assume there is no common ancestor (which there isn't yet). The --incremental switch will make svk merge each commit to your local branch as a separate commit to the upstream repository. And finally the --verbatim switch will cause the log messages of the commits to the upstream repository to be identical to the original ones in your local svk depot.