![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
index bd163cfad6385f2525f818a8eb851c2a205d5da4..9b5a3d61966eaa8d24b5ee507f2e1be770a1c367 100644 (file)
(--tags=project/tags') or a full url
(--tags=https://foo.org/project/tags)
---prefix=<prefix>
+--no-metadata::
+ Set the 'noMetadata' option in the [svn-remote] config.
+--use-svm-props::
+ Set the 'useSvmProps' option in the [svn-remote] config.
+--use-svnsync-props::
+ Set the 'useSvnsyncProps' option in the [svn-remote] config.
+--rewrite-root=<URL>::
+ Set the 'rewriteRoot' option in the [svn-remote] config.
+--username=<USER>::
+ For transports that SVN handles authentication for (http,
+ https, and plain svn), specify the username. For other
+ transports (eg svn+ssh://), you must include the username in
+ the URL, eg svn+ssh://foo@svn.bar.com/project
+
+--prefix=<prefix>::
This allows one to specify a prefix which is prepended
to the names of remotes if trunk/branches/tags are
specified. The prefix does not automatically include a
This fetches revisions from the SVN parent of the current HEAD
and rebases the current (uncommitted to SVN) work against it.
- This works similarly to 'svn update' or 'git-pull' except that
- it preserves linear history with 'git-rebase' instead of
- 'git-merge' for ease of dcommit-ing with git-svn.
+This works similarly to 'svn update' or 'git-pull' except that
+it preserves linear history with 'git-rebase' instead of
+'git-merge' for ease of dcommit-ing with git-svn.
- This accepts all options that 'git-svn fetch' and 'git-rebase'
- accepts. However '--fetch-all' only fetches from the current
- [svn-remote], and not all [svn-remote] definitions.
+This accepts all options that 'git-svn fetch' and 'git-rebase'
+accepts. However '--fetch-all' only fetches from the current
+[svn-remote], and not all [svn-remote] definitions.
- Like 'git-rebase'; this requires that the working tree be clean
- and have no uncommitted changes.
+Like 'git-rebase'; this requires that the working tree be clean
+and have no uncommitted changes.
'dcommit'::
Commit each diff from a specified head directly to the SVN
alternative to HEAD.
This is advantageous over 'set-tree' (below) because it produces
cleaner, more linear history.
+--
'log'::
This should make it easy to look up svn log messages when svn
users refer to -r/--revision numbers.
++
+The following features from `svn log' are supported:
++
+--
+--revision=<n>[:<n>];;
+ is supported, non-numeric args are not:
+ HEAD, NEXT, BASE, PREV, etc ...
+-v/--verbose;;
+ it's not completely compatible with the --verbose
+ output in svn log, but reasonably close.
+--limit=<n>;;
+ is NOT the same as --max-count, doesn't count
+ merged/excluded commits
+--incremental;;
+ supported
+--
++
+New features:
++
+--
+--show-commit;;
+ shows the git commit sha1, as well
+--oneline;;
+ our version of --pretty=oneline
+--
++
+Any other arguments are passed directly to `git log'
- The following features from `svn log' are supported:
-
- --revision=<n>[:<n>] - is supported, non-numeric args are not:
- HEAD, NEXT, BASE, PREV, etc ...
- -v/--verbose - it's not completely compatible with
- the --verbose output in svn log, but
- reasonably close.
- --limit=<n> - is NOT the same as --max-count,
- doesn't count merged/excluded commits
- --incremental - supported
-
- New features:
-
- --show-commit - shows the git commit sha1, as well
- --oneline - our version of --pretty=oneline
-
- Any other arguments are passed directly to `git log'
-
+--
'set-tree'::
You should consider using 'dcommit' instead of this command.
Commit specified commit or tree objects to SVN. This relies on
Make git-svn less verbose.
--repack[=<n>]::
---repack-flags=<flags>
- These should help keep disk usage sane for large fetches
- with many revisions.
+--repack-flags=<flags>::
- --repack takes an optional argument for the number of revisions
- to fetch before repacking. This defaults to repacking every
- 1000 commits fetched if no argument is specified.
+These should help keep disk usage sane for large fetches
+with many revisions.
- --repack-flags are passed directly to gitlink:git-repack[1].
+--repack takes an optional argument for the number of revisions
+to fetch before repacking. This defaults to repacking every
+1000 commits fetched if no argument is specified.
+--repack-flags are passed directly to gitlink:git-repack[1].
+
+[verse]
config key: svn.repack
config key: svn.repackflags
------------------------
--
-svn.noMetadata:
-svn-remote.<name>.noMetadata:
- This gets rid of the git-svn-id: lines at the end of every commit.
-
- If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
- be able to rebuild it and you won't be able to fetch again,
- either. This is fine for one-shot imports.
-
- The 'git-svn log' command will not work on repositories using
- this, either. Using this conflicts with the 'useSvmProps'
- option for (hopefully) obvious reasons.
-
-svn.useSvmProps:
-svn-remote.<name>.useSvmProps:
- This allows git-svn to re-map repository URLs and UUIDs from
- mirrors created using SVN::Mirror (or svk) for metadata.
-
- If an SVN revision has a property, "svm:headrev", it is likely
- that the revision was created by SVN::Mirror (also used by SVK).
- The property contains a repository UUID and a revision. We want
- to make it look like we are mirroring the original URL, so
- introduce a helper function that returns the original identity
- URL and UUID, and use it when generating metadata in commit
- messages.
-
-svn.useSvnsyncProps:
-svn-remote.<name>.useSvnsyncprops:
+svn.noMetadata::
+svn-remote.<name>.noMetadata::
+
+This gets rid of the git-svn-id: lines at the end of every commit.
+
+If you lose your .git/svn/git-svn/.rev_db file, git-svn will not
+be able to rebuild it and you won't be able to fetch again,
+either. This is fine for one-shot imports.
+
+The 'git-svn log' command will not work on repositories using
+this, either. Using this conflicts with the 'useSvmProps'
+option for (hopefully) obvious reasons.
+
+svn.useSvmProps::
+svn-remote.<name>.useSvmProps::
+
+This allows git-svn to re-map repository URLs and UUIDs from
+mirrors created using SVN::Mirror (or svk) for metadata.
+
+If an SVN revision has a property, "svm:headrev", it is likely
+that the revision was created by SVN::Mirror (also used by SVK).
+The property contains a repository UUID and a revision. We want
+to make it look like we are mirroring the original URL, so
+introduce a helper function that returns the original identity
+URL and UUID, and use it when generating metadata in commit
+messages.
+
+svn.useSvnsyncProps::
+svn-remote.<name>.useSvnsyncprops::
Similar to the useSvmProps option; this is for users
of the svnsync(1) command distributed with SVN 1.4.x and
later.
-svn-remote.<name>.rewriteRoot
+svn-remote.<name>.rewriteRoot::
This allows users to create repositories from alternate
URLs. For example, an administrator could run git-svn on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
-
Since the noMetadata, rewriteRoot, useSvnsyncProps and useSvmProps
options all affect the metadata generated and used by git-svn; they
*must* be set in the configuration file before any history is imported
--
-Basic Examples
-~~~~~~~~~~~~~~
+BASIC EXAMPLES
+--------------
Tracking and contributing to a the trunk of a Subversion-managed project:
# with the appropriate name):
git reset --hard remotes/trunk
# You may only dcommit to one branch/tag/trunk at a time. The usage
-# of dcommit/rebase/show-ignore should be teh same as above.
+# of dcommit/rebase/show-ignore should be the same as above.
------------------------------------------------------------------------
REBASE VS. PULL/MERGE