svn relocate
This documentation was written to describe the 1.7.x series of
Apache(TM) Subversion(R).
If you are running a different
version of Subversion, you are strongly encouraged to visit
instead consult the version of this documentation appropriate for
your version of Subversion.
svn relocate — Relocate the working copy to point to a
different repository root URL.
svn relocate FROM-PREFIX TO-PREFIX [PATH...]
svn relocate TO-URL [PATH]
Description
Sometimes an administrator might change the location
(or apparent location, from the client's perspective) of a
repository.
The content of the repository doesn't change,
but the repository's root URL does.
The hostname may
change because the repository is now being served from a
different computer.
Or, perhaps the URL scheme changes
because the repository is now being served via SSL
(using https://) instead of over plain
There are many different reasons for these types of
repository relocations.
But ideally, a “change of
address” for a repository shouldn't suddently cause
all the working copies which point to that repository to
become forever unusable.
And fortunately, that's not the
Rather than force users to check out a new working
copy when a repository is relocated, Subversion provides
the svn relocate command, which
“rewrites” the working copy's administrative
metadata to refer to the new repository location.
The first svn relocate syntax
allows you to update one or more working copies by what
essentially amounts to a find-and-replace within the
repository root URLs recorded in those working copies.
Subversion will replace the initial substring
FROM-PREFIX with the
string TO-PREFIX in those URLs.
These initial URL substrings can be as long or as short as
is necessary to differentiate between them.
Obviously, to
use this syntax form, you need to know both the current
root URL of the repository to which the working copy is
pointing, and the new URL of that repository.
(You can use svn info to determine
the former.)
The second syntax does not require that you know the
current repository root URL with which the working copy is
associated at all—only the new repository URL
(TO-URL) to which it should be
In this syntax form, only one working copy may
be relocated at a time.
Users often get confused about the difference
between svn switch and svn
Here's the rule of thumb:
If the working copy needs to reflect a new
directory within the
repository, use svn
If the working copy still reflects the
same repository directory, but the location of the
repository itself has changed, use svn
Let's start with a working copy that reflects a local
repository URL:
One day the administrator decides to rename the
on-disk repository directory.
We missed the memo, so we
see an error the next time we try to update our working
After cornering the administrator over by the vending
machines, we learn about the repository being moved and
are told the new URL.
Rather than checkout a new working
copy, though, we simply ask Subversion to rewrite the
working copy metadata to point to the new repository
Subversion doesn't tell us much about what it did, but
hey—error-free operation is really all we need,
Our working copy is functional for online
operations again.
Once again, this type of relocation
affects working copy metadata only.
It will not change your versioned or unversioned file
contents, perform any version control operations (such
as commits or updates), and so on.
A few months later, we're told that the company is
moving development to separate machines and that we'll be
using HTTP to access the repository.
So we relocate our
working copy again.
Now, each time we perform a relocation of this sort,
Subversion contacts the repository—at its new URL,
of course—to verify a few things.
First, it wants to compare the UUID of the repository
against what is stored in the working copy.
If these UUIDs
don't match, the working copy relocation is disallowed.
Maybe this isn't the same repository (just in a new
location) after all?
Secondly, Subversion wants to ensure that the updated
working copy metadata jives with respect to the directory
location inside the repository.
Subversion won't let you accidentally relocate a working
copy of a branch in your repository to the URL of a
different branch in the same repository.
what svn switch, described in
, is for.)
Also, Subversion will not allow you to relocate a
subtree of the working copy.
If you're going to relocate
the working copy at all, you must relocate the whole
This is to protect the integrity of the working
copy metadata and behavior as a whole.
(And really, you'd
be hard pressed to come up with a compelling reason to
relocate only a piece of your working copy anyway.)
Let's look at one final relocation opportunity.
using HTTP access for some time, the company moves to
SSL-only access.
Now, the only change to the repository
URL is that the scheme goes from
being http:// to
being https://.
There are two
different ways that we could make our working copy reflect
ths change.
The first is to do exactly as we've done
before and relocate to the new repository URL.
But we have another option here, too.
We could simply
ask Subversion to swap out the changed prefixes of the
Either approach leaves us a working copy whose
metadata has been updated to point to the right repository
By default, svn relocate will
traverse any external working copies nested within your
working copy and attempt relocation of those working
copies, too.
Use the --ignore-externals
option to disable this behavior.君，已阅读到文档的结尾了呢~~
SVN基本操作基本,操作,帮助,SVN,svn,基本操作,大数据
扫扫二维码，随身浏览文档
手机或平板扫扫即可继续访问
SVN基本操作
举报该文档为侵权文档。
举报该文档含有违规或不良信息。
反馈该文档无法正常浏览。
举报该文档为重复文档。
推荐理由：
将文档分享至：
分享完整地址
文档地址：
粘贴到BBS或博客
flash地址：
支持嵌入FLASH地址的网站使用
html代码：
&embed src='/DocinViewer--144.swf' width='100%' height='600' type=application/x-shockwave-flash ALLOWFULLSCREEN='true' ALLOWSCRIPTACCESS='always'&&/embed&
450px*300px480px*400px650px*490px
支持嵌入HTML代码的网站使用
您的内容已经提交成功
您所提交的内容需要审核后才能发布，请您等待！
3秒自动关闭窗口1.基本操作
1.0 创建版本库：&
&Svnadmin&create&/data/repos &
2.0 修改配置文件&Auth文件 &&[groups] &&admin=shguo &&[/] &&@admin=rw &&*=r &[groups] admin=shguo [/] @admin=rw *=rPasswd文件[users] &&shguo=shguo &[users] shguo=shguoSvnserve.conf文件anon-access = read &&auth-access = write &&password-db = passwd &&authz-db = authz &
注意：要去掉前面的空格不然会报，认证配置失败&
svnserve&&d &r repos &
4.0 创建目录svn&mkdir&svn://127.0.0.1/repos/ -m &mkdir& &（说明&&中是提交的log注释）svn&mkdir&svn://127.0.0.1/repos/sns/ &-m &mkdir& &&svn&mkdir&svn://127.0.0.1/repos/sns/trunk &-m &mkdir& &&svn&mkdir&svn://127.0.0.1/repos/sns/branches -m &mkdir& &&svn mkdir&svn://127.0.0.1/repos/sns/tags &-m &mkdir&或者本地操作svn&mkdir&file:///data/repos/ -m &mkdir&&svn&mkdir&file:///data/repos/sns/ -m &mkdir&&svn&mkdir&file:///data/repos/sns/trunk -m &mkdir&&svn&mkdir&file:///data/repos/sns/branches -m &mkdir&&
svn&mkdir&file:///data/repos/sns/tags -m &mkdir&&
5.0导入项目：Svn&import&sns svn://127.0.0.1/repos/sns/trunk/ &m &init project& &&查看：svn&list&svn://127.0.0.1/repos/sns/trunk/&&6.0导出项目开发：
Svn&checkout&svn://127.0.0.1/repos/sns/trunk/sns&
7.0进入目录就可以进行开发操作了Cd sns &&Svn&status &&Svn&add &new.txt &&Svn&commit&&m &commit& &Svn&log&new.txt其它一些命令：Svn&update & &Svn&diff&&r m:n path &&Svn&lock&some.java or svn unlock some.java &&Svn&revert & &Svn&add&/delete&/&copy&/&move &&Svn&switch&&relocate svn://xxxx/one & svn://xxxx/two &&
Svn&list&path &
2. Svn中分支的使用&
2.0 创建分支Svn&cp&/repos/sns/trunk/ &/repos/sns/branches/101128_sns_imageUpload_shguo -m &shguo_branch& &也可以通过 TortoiseSVN 中的Branch/tag来创建分支&
2.1 取出分支来开发&
Svn&co&/repos/sns/branches/101128_sns_imageUpload_shguo &101128_sns_imageUpload_shguo
2.2开发完成后向主干提交&检查需要合并的分支的历史:svn&log&--stop-on-copy -q /repos/sns/branches/101128_sns_imageUpload_shguo合并：svn&merge&&r 16:HEAD /repos/sns/branches/101128_sns_imageUpload_shguo2.3检查冲突：&svn status&如果有解决冲突，没有就svn commit命令就可以完成提交&2.4 批量增加svn文件svn&add&`svn st |grep ? |awk '{print $2}'` &&svn&st&|grep ? |awk '{print $2}' |xargs svn add &2.5 批量增加svn:ignore属性svn&propset&svn:ignore &-F ~/.svnignore -R /app/work/app1 &------------------------------------------------------------------------------------------整个具体流程总结如下 :1.建立两套服务器.配置一致.程序发布的目录等设置也保持一致 如：(QA环境 生产环境)2.其中一套作为开发测试环境使用.一套作为生产环境使用3.SVN建立trunk目录作为主代码分支，,建立branch目录作为其他分支；如svn://project/trunk & &svn://project/branch4.开发人员使用branch分支进行开发；（问题点：开发自测和QA测试环境）5.当确认某个测试版本稳定后.将branch分支的内容合并(merge)到主干.6.运维将测试环境主干代码update到生产环境；&3.分支使用命令示例：3.0 创建分支
svn cp http://..../project/trunk &http://..../project/branch/mall_bugid3012_order -m &order&
3.1 取出分支开发3.2 开发完成后提交
3.3 检查需要合并的分支记录
& &svn&log&&stop-on-copy &q http://..../project/branch/mall_bugid3012_order
& &svn&merge&&r &旧版本号:新版本号(head) http://..../project/branch/mall_bugid3012_order & & &&
3.5 检查冲突和提交
& &svn&status&& &svn&commit
阅读(...) 评论()TortoiseSVN&Switch与Relocate的区别
http://blog.csdn.net/cdh1213/article/deta
项目地址发生变化之后
只需要在项目的头上右键 svn&Relocate 一下 将地址更改为最新错的即可
如果是在eclipse里面 还需要将项目关闭 然后再引入进来
将之前先明确两个概念，工作副本就是本地的代码的目录，工作目录就是SVN服务器端的与本地工作副本相对应的目录。
Switch是转换当前工作副本对应的工作目录，一般是从trunk工作目录转向tag工作目录，或者从tag转回来，switch的类似update，将switch的目标工作目录的文件更新到本地，一般会产生很多冲突。
Relocate是当代码仓库的访问路径（服务器的计算机名称修改，或IP地址变更，URL变更），而此时已检出修改的工作副本（working
copy）没有变更，若此时直接提交（commit），肯定不能成功，因为此提交地址对应的svn服务器不存在了。TortoiseSVN为我们提供了重定位工作副本的功能（TortoiseSVN
→ Relocate），此指令扫描.svn文件夹中的所有条目，改变条目的url（服务器地址）为新输入的地址。
重定位操作可能的原因：
a) 服务器的IP地址已更改
b) 协议已更改(比如从http://改为
c) 版本库在服务器的路径已更改
在TortoiseSVN的帮助说明中说明重定位是极少使用的操作，但对于在本地小型内网开发的，由于重装系统，服务器主机变动，重定位应用还是比较多的。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。