xcode 4 with subversion SVN server–Tips

修改subversion.config方法：

可以直接在终端上输入:vi ~/.subversion/config来编辑.
也可以通过Finder搜索.subversion,点击下边的+号,进入高级搜索界面,找到各类->其他-> 文件可见性 ,选择不可见文件即可搜索到.subversion文件夹.
隐藏文件文件名是 .subversion

mac下怎么保存终端下更改的项目(^O WriteOut)

As newly anointed Xcode developers, and now with the release of Xcode 4. We found our team working on trying to get connected to a new subversion (svn) server at the same time we were trying to discover some new features of Xcode 4.

about challenging.

Actually this was the first time with anything Apple we have not had a great experience. Loads of talk etc on the net about what a pain in the bum it all is.

For those who don’t know. Subversion is a code storage system that allows check in / check out of developer Xcode to a server. There are services online that you can pay monthly to for the use of a SVN server. We wanted to host it on one of our own servers.

The setup was not easy and required the setup of a new Linux server, then the setup of the SVN code to turn it into an SVN server.

What became confusing was when we needed to get Xcode to talk to the darn thing. Here is the important things you need to know.

First Contact

Just like the movie from when I was a kid, “First encounter” is a big deal! Big enough to heap your mashed potato into a big mountain!

1. Open Xcode and select Window / Organiser.

2. Select Repositories

3. Bottom left, click the +

4. Add the details of the SVN server. Like this: svn://www.servername.com/directory (this should be the details for your SVN Server).

5. Where asked for Trunk Branches and Tags (leave empty for now).

Now we nee to use the “Terminal” program to make a connection to SVN.

1. Create a test.txt file with some simple message in it. Save it in your documents folder on your mac.

2. Open Terminal

3. Type “svn import /Users/yourname/Documnets/test.txt svn://www.servername.com/directory -m“initial import” –username yourname

Note:

the path “/Users/yourname/Documnets/test.txt” should be a path to any single dummy test.txt file. The idea is that we are uploading a single file to establish a connection.

The: svn://www.servername.com/directory is the path to your SVN server

“initial import” is only a tag line. Not needed

–username yourname = This is your SVN user name. Ensure you use a double dash –username.

EG: our code looks like this:

svn import /Users/spascoe/Documents/Temp/test.txt svn://www.interactivewebs.com/interactivewebs -m “test import”

4. You will be prompted with your existing user for your user password. At this point, if your mac user name does not match the configured SVN user name. Just hit enter. It will then prompt of a user. Type the new SVN user name, then enter. Then the configured SVN pass and enter.

5. You will likely see something that says. “svn://www.servername.com/directory already exists” – Ignore that!

6. Close Xcode

7. Open Xcode again and return to the Optimizer / Repositories and with luck, your server will list on the left hand side, and show the ROOT and any folders on the SVN server.

8. Click back on the server name in the left hand column.

9. Type in the names of the Trunk Branches and Tags folders. We chose to use these names to make it easy. They need to be setup on the SVN server by the administrator. They ARE case sensitive.

10. The text.txt file can be deleted from the server through Xcode if desired.

11. Close the terminal session.

Thoughts

Sometimes not all views refresh correctly. We suggest closing Xcode and opening it again to get things visible that you know should be there.

If you need to change user names, and or passwords. Then you will need to enter the terminal again and upload something using the method above.

We don’t understand exactly why, but it appears that Xcode will remember the authentication of the terminal session, and caches the authentication properties some place. Without the terminal session upload, you will never get it working!

配置Xcode SVN从零开始

本节介绍一下从零配置Xcode SVN，Xcode 2.0 是开发人员建立 Mac OS X 应用程序的最快捷方式，也是利用新的苹果电脑公司技术的最简单的途径，而SVN是版本控制工具，那么Xcode SVN又是什么呢?如何配置Xcode SVN？本节就向大家一一讲解。
一、SVN干什么用的？
如果你重没接触过svn，也许这篇文章会对你有点帮助。一个大project总是很多人一起在开发，每个人都会更新这个project的sourcecode，svn就是为了方便大家一起维护管理sourcecode而诞生的。（svn真是不可多得的好东西！很奇怪LTE那么大的工程那么多人做，实验室怎么没人提倡用svn呢？）
我刚开始自学iphone的时候真的特别笨！代码需要一次又一次的修改，但有时修改后反而不能运行又找不出错在哪儿，“恢复”原来版本重新修改是一种好办法，可惜那时候我没听说过svn走了很多弯路，我人工的为每个project存储了很多版本，最后搞得自己也不知道哪个版本能用不能用了，实在费时费力又没效率！后来yile大大教我在Xcode上配置使用svn，生产力一下子从原始社会进入封建社会，省了不少事啊。
二、Xcode SVN配置方法
Mac自带svn，所以我们就不需要下载了，稍稍修改一下subversion配置就能使用。大大教了两种方法：方法一、适合团队合作的当然是把sourcecode放在服务器上，这样大家都可以下载、更新，不过通常这种服务器都是要收费滴（公司内网设个服务器是不是可用，这个我还没学）；方法二、如果只是用于管理自己的程序，那么直接把本机当作服务器来配置就可以了～
配置Xcode SVN方法一：
Leopard中自带了SVN，但Xcode的项目文件中，并不是所有文件都适于加入SVN中进行管理，比如编译后的文件和编译过程中产生的文件，这些文件不属于源代码，应该告诉svn忽略掉，方法：
编辑~/.subversion/config文件
1.找到global-ignores一行，去掉注释，编辑成
global-ignores=build*~.nib*.so*.pbxuser*.mode*.perspective*.DS_Store
Xcode项目文件中有些文件是文本文件，需要告诉SVN，因为SVN能更好地管理文本文件
2.找到enable-auto-props=yes把注释去掉，在[auto-props]Section声明以下文本文件
*.mode*=svn:mime-type=text/X-xcode
*.pbxuser=svn:mime-type=text/X-xcode
*.perspective*=svn:mime-type=text/X-xcode
*.pbxproj=svn:mime-type=text/X-xcode
先去http://svn.w18.net/注册一个帐号，可以免费使用一个月练练手。登录后创建一个项目,打开Xcode->SCM->ConfigureSCMRepositories，填写信息如下图，然后我们就可以import、checkout操作了，这里解释一下库（repository）和服务器、本机之间的关系。库记录着所有版本的代码信息，无论你是从服务器下载更新代码（update）还是想将本地修改后的代码上传至服务器（commit）都要经过Repository；它就像一个仓库，从厂家运来的货物、卖出去的货物都记录得清清楚楚，随时查随时有。第一次使用时，服务器上没有sourcecode，需要将第一份源码import到库中，库就自动将sourcecode上传至服务器了。接下来，怎么更新、上传源码呢？通过checkout可以将服务器上代码下载至本机指定路径，那么每次修改代码后，commit操作即可更新本地代码至服务器，而update可将服务器上最新版本更新至本机，如果你想恢复以前某个版本也很简单，updateto某个revision版本即可（由于学校教育网，无法连接至服务器，具体操作在方法二中演示）。
配置Xcode SVN方法二：
也许你只是想管理一下自己的代码，不需要服务器，那么直接把本机当服务器使用就好了。
1、打开终端，cd到你想要的路径，svnadmincreatelib创建一个数据库用于管理储存你的代码。我创建的lib路径为/Users/maffia/lib
2、配置SCM信息如下。接下来，import你的工程路径（类似方法一将源代码上传至服务器），然后checkout（同方法一将服务器代码下载至本机），然后这个工程代码就可以随你修改了，SCM会聪明的为你管理代码而不用你操一点心。
打开checkout至本机的工程，SCM->ConfigureSCMForThisProject,然后为该工程选择本地subversion，我这里的名字是localsvn_test。这时如果你修改了文件代码，下图高亮处为我添加内容，储存后，修改的文件名左边会多出一个M，如果没有检查一下SCM状态是否Online。
接下来SCM->commit就会将你的版本更新至库，服务器上信息也随之更新。我修改两次后，查看SCMinfo发现了3个版本，它真的是很聪明的管家啊。所以什么时候你要是改代码改得不知所措了，只需将update至以前能用的版本即可，就像timemachine一样非常方便。本文关于配置Xcode SVN讲解完毕，请关注本节其他相关报道。

Xcode中SVN相关问题大串讲

本节向大家讲解一下Xcode中SVN的相关问题，主要有三部分，在这里和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，欢迎大家一起来学习Xcode中SVN方面的知识。下面是具体讲解。

在Xcode中SVN如何使用
不管是Web,iPhone和Mac的开发，SVN(Subversion),已经成为我每天开发中须臾不可以离的朋友，但是这个工具对于普通的个人开发者来说有点奢侈，如果不在互联网租用一台服务器（约7000元每年）的话，是很难享用那么方便的工具的。于是我们两年前做了一个SVN的平台，svn.w18.net，把我们在广州电信的服务器的Subversion服务器共享出来，希望对大家有用，对于开源的项目是免费的，私有项目100元每年。
Xcode3.0以上可以完美支持SVN,今天和大家分享一下在Xcode中使用SVN的经验。
第一步，配置Subversion
Xcode中SVN使用时需要配置Subversion。Leopard中自带了SVN，但Xcode的项目文件中，并不是所有文件都适于加入SVN中进行管理，比如编译后的文件和编译过程中产生的文件，这些文件不属于源代码，应该告诉svn忽略掉，方法：编辑~/.subversion/config文件
1.找到global-ignores一行，去掉注释，编辑成
global-ignores=build*~.nib*.so*.pbxuser*.mode*.perspective*
Xcode项目文件中有些文件是文本文件，需要告诉SVN，因为SVN能更好地管理文本文件（谁用谁知道）
2.找到enable-auto-props=yes把注释去掉，在[auto-props]Section声明以下文本文件
*.mode*=svn:mime-type=text/X-xcode
*.pbxuser=svn:mime-type=text/X-xcode
*.perspective*=svn:mime-type=text/X-xcode
*.pbxproj=svn:mime-type=text/X-xcode
第二步，配置Xcode
我们熟悉的VersionControl在Xcode中叫做SCM（SoftwareConfigurationManagement，学习CMMI的时候整天看到，原来就是VersionControl）。
1.在Xode的菜单中选择SCM->ConfigureRepositories，填写SVN服务器的信息
2.然后选SCM->Repositories你就可以Import,CheckOut你想要的内容了，SVN的日常管理也可以在这里做。
3.Checkout项目以后在你的项目的属性中设置项目的SCM。
4.设置好以后，你在你的项目视图中就可以看到新的一列，M表示该文件已经修改过，然后你已经可以通过SCM菜单，或者右键菜单直接进行SVN的操作，commit，update，revert，diffandlog，任何你想要的。SCM->GetSCMInfo可以看到任何文件的版本信息。
XCode中SVN配置
我们在团队开发时，需要使用版本管理辅助我们来管理代码，提高效率。在xcode中直接支持与cvs,svn等版本管理方式。下面来介绍一下如何在xcode下进行
svn资源库的配置：
1。打开xcode后我们在菜单中就会看到scm这个菜单组，点击这个菜单组后选择configurescmrepositories,当然，你也可以在你打开一个工程后将这每一个工程文件提交到不同的版本管理的仓库中。
2。点击添加（此时默认选择为repository)，类型选择svn,然后在弹出的表单中进行填写：如下
name:iphone_respositories
URL:svn://用户名@资源库url:3690
scheme:svn
host:资源库url，如www.blessdyb.com
port:3690
最终写入用户名与密码即可
如何使Xcode中支持最新的SVN
使用MacPorts安装了最新的svn后,使用命令行checkout出来的工程,在Xcode中,执行SCM->update时,会报告"Thisclientistoooldtoworkwithworkingcopy‘.’;pleasegetanewerSubversionclient"的错误.在http://subversion.tigris.org/getting.html#osx下载mac下面的最新subversion安装包.
1)cp/opt/subversion/bin/svn*/usr/bin/
2)cpopt/subversion/lib/*/usr/lib/
由于想更新10.5.7到10.6了,所以就直接覆盖到了这两个目录.如果系统比较稳定,且想长期使用下去当前版本的朋友,请使用其他更保险的方法来设置。本文关于Xcode中SVN内容介绍完毕。

两种常见SVN库结构简明介绍

本节和大家一起学习一下SVN库结构，SVN库结构常见的主要有两种，本节做一个简单的介绍，希望通过本文SVN库结构的学习能够拓宽你的视野。
很多人对”推荐的版本库结构？”不是很清楚。””trunk有什么意义？”。
一个SVN版本库实现了一种版本化的文件系统，版本库只是一个包含目录和文件的文件系统，而且它的文件系统是版本化的，并且实现了”廉价”拷贝，让它的这种操作比传统文件系统便宜很多，但是版本库本身还是像一个文件系统：SVN本身没有特别的目录或名称用来代表trunk或branches，他们只是文件系统的普通目录，这依赖于你给这些目录名和结构的一种意义。
也就是说，社区已经采纳了多种普通的库结构作为最佳实践，因此一个人可以将其视为推荐方式。如果你的版本库是公共访问的，根据这些习惯，用户可以方便的访问版本库来查找他们所需要的。
有两种常见的SVN库结构：
第一种SVN库结构：
trunk
branches
tags
版本库包含一个项目或一组紧密联系项目的最佳选择，这个库结构非常好用，因为分支与标签整个项目或一组项目会非常简单，只需要一个简单的命令：
svncopyurl://repos/trunkurl://repos/tags/tagname-m"Createtagname"
这可能是最常用的版本库结构，被许多开源项目采用，就像Subversion本身和Subclipse，这是大多数主机站点，如Tigris.org,SourceForge.net和GoogleCode遵循的方法，这些站点的每个项目有自己的版本库。
另一种SVN库结构是针对一个版本库包含不相关项目的最佳选择。
ProjectA
trunk
branches
tags
ProjectB
trunk
branches
tags
在这种库结构里，每个项目会存在顶级目录里，然后该目录之下创建trunk/branches/tags，其中与第一种库结构相同，这只是将项目放到自己版本库方式的替换，他们都在一个版本库中。Apache软件基金会使用这种库结构方式来存放他们的所有项目在一个版本库。
通过这种库结构，每个项目都有自己的分支和标签，可以很容易使用一个命令创建分支和标签，就像前面展示的：
svncopyurl://repos/ProjectA/trunkurl://repos/ProjectA/tags/tagname-m"Createtagname"
这种库结构可以简单的创建同时包含ProjectA和ProjectB的标签，你可以这样做，但是需要多个命令，你也要决定是否创建一个特别的目录存放这种分支和标签，如果你需要经常这样做，你或许应该考虑第一种SVN库结构。至于版本库中目录的名称，再说一遍：只是一种习惯，他们在Subversion中没有特别含义。

“trunk”可以认为是项目的开发主线，你可以称之为“main”，”mainline”，”production”或任何你喜欢的名字。
“branches”是放置分支的地方，人们因各种目的使用分支，你或许希望通过特性分支或客户修改分支来隔离你的发布或维护分支等，在这个例子里，你可以在branches创建一层目录，或只是在顶级目录创建多个分支目录。
“tags”也不会被SVN特别对待，他们只是习惯，或许通过钩子脚本或授权规则进行强制，来指明你创建了一个时间点的快照，通常情况下tags与分支的区别就是tags一旦创建不能修改，你也可以将标签目录叫做”releases”，”snapshots”，”baselines”或任何你喜欢的。记住，名称对你有意义，不是SVN。最后，SVN的架构，全局修订版本经常使得标签没有必要，我不知道只是因为要创建tag而创建tag有什么意义，如果你需要在特定时间点重建软件，你可以通过svnlog来确定相关的修订版本号。tags对于版本库的”外部”用户很有用，或许QA/Release团队需要执行构建，或许是一个内部开发小组希望在另一个产品使用发布版本，或是外部用户或客户希望根据字面含义从版本库获取发布快照，在这些场景中，创建tag是保证获取正确代码的最简单方法，也需要有好的交流机制来指明发布快照。
最后，我希望指出SVN版本库的库结构是可以修改的，你可以一直重组和重构库结构，最坏情况下，会让用户调整他们的工作拷贝，但不会让你从头再来，你应该自由的改名，移动目录或任何你希望改变版本库的方式去做。本文关于SVN库结构的内容讲解完毕。

SVN库迁移及备份方法详解

本节向大家简单讲解一下SVN库迁移及备份方案，在学习SVN的过程中难免会遇到SVN库的问题，在这里和大家分享一下SVN库迁移及备份方面的知识，希望对你的学习有所帮助。

在做迁移操作前，请停止对svn进行提交操作。
1.SVN库迁移方案（采用dump-load方案）：
源SVN服务器：192.168.1.200，Windows服务器
目标SVN服务器：192.168.1.201，Windows服务器。采用CollabNetSubversionServer，假定subversion安装在D:\ProgramFiles\CollabNetSubversionServer上，SVN的Repository为d:\Subversion\svnbackup
也即Windows服务中，可执行文件的路径为：“d:\ProgramFiles\CollabNetSubversionServer\svnserve.exe”–service-r“d:\Subversion\svnbackup”–listen-port“3690″
由于目前在subversion服务器上实际上只有svn://192.168.1.200/rd目录下才有内容，因此只需要迁移svn://192.168.1.201/rd下的内容，步骤如下：
1、在源服务器192.168.1.200上执行dump操作
注意此处实际上把repository中所有的目录都备份了，需要在load时候采用svndumpfilter命令过滤需要的目录。
svnadmindumpD:\Subversion\svnworkspace\bak>svn_all_20080520.dump
2、在192.168.1.201上创建svnbackupRepository
svnadmincreated:\Subversion\svnbackup
3、下载一个windows版本gnu工具(例如http://sourceforge.net/projects/gnuwin32/)，主要是使用cat方法
4、将dump文件拷贝到上并执行load操作
catsvn_all_20080520.dump|svndumpfilter--include:rd>svn_rd_20080520.dump5、执行svnadminload
svnadminloadd:\Subversion\svnbackup<svn_rd_20080520.dump6、在192.168.1.201上配置svnserve.conf、passwd、authz文件
2.SVN库迁移方案（采用svnsync方案）
从subversion1.4.4开始，提供了svnsync命令，可用于Subversion的库迁移和备份，这里我们用于备份操作的初始化同步。
假定从源服务器192.168.1.201备份到192.168.1.88
SVN服务器：192.168.1.201，Windows服务器，采用CollabNetSubversionServer，假定subversion安装在D:\ProgramFiles\CollabNetSubversionServer上，SVN的Repository为d:\Subversion\svnbackup。
备份服务器：192.168.1.88，RedhatAs4服务器
采用svnsync进行数据迁移，方法如下：
1、在备份服务器192.168.1.88上创建源服务器192.168.1.201上对应的备份库目录
mkdir/opt/subversion
svnadmincreate/opt/subversion/svnbackup
2、在备份服务器192.168.1.88上启用钩子文件
cd/opt/subversion/svnbackup/hooks
echo“#!/bin/sh”>pre-revprop-change
chmod755pre-revprop-change
3、在备份服务器192.168.1.88上运行svnsyncinit命令
svnsyncinitfile:////opt/subversion/svnbackupsvn://192.168.1.201–usernameusername–passwordpassword
注意，svnsync的语法为：svnsyncinitDESTSOURCE
4、在备份服务器192.168.1.88上执行同步操作
svnsyncsyncfile:////opt/subversion/svnbackup
由于svnsyc只能同步整个svn库，并不能同步指定的项目，因此建议迁移时候使用dump-load方案，备份时候采用svnsync方案
3.SVN库备份方案：
为保证svn服务器的安全，由脚本每天定时对svn库进行备份，以保证svn库的安全性。备份仍然采用svnsync来完成。
1.在192.168.1.88上安装subversion服务器端
2.在192.168.1.88上创建备份用户帐号svnsync，以供192.168.1.201能够以此帐号实时把变更的同步到192.168.1.88上
配置文件svnserve.conf：
[general]
anon-access=none
auth-access=write
password-db=passwd
authz-db=authz
配置文件passwd：
svnsync=svnsync
配置文件authz
[groups]
developer=svnsync[/]
@developer=rw*=
3.在备份机上开启iptables的3690端口
4.在备份机192.168.1.88上创建备份库目录
svnadmincreate/opt/subversion/svnbackup
chown–Rsvnsync:svnsync/opt/subversion/svnbackup
5.按照上述采用svnsync方案的步骤，将库同步到192.168.1.88上，初始化svn库
cd/opt/subversion/svnbackup/hooks
echo“#!/bin/sh”>pre-revprop-change
chmod755pre-revprop-change
svnsyncinitfile:////opt/subversion/svnbackupsvn://192.168.1.201–usernameusername–passwordpassword
svnsyncsyncfile:////opt/subversion/svnbackup
6.在源服务器192.168.1.201上，创建钩子文件，保证192.168.1.201上的变动实时同步到192.168.1.88上：
post-commit
#PropagatethedatatotheremoterepositoryD:\ProgramFiles\CollabNetSubversionServer\svnsyncsynchronize--usernamesvnsync--passwordsvnsyncsvn://192.168.1.88post-rev-changes
#Propagatingchangestotheremoterepository.D:\ProgramFiles\CollabNetSubversionServer\bin\svnsynccopy-revprops--usernamesvnsync--passwordsvnsyncsvn://192.168.1.88$REV4.参考文档：http://blog.notreally.org/articles/2006/11/30/setting-up-a-subversion-mirror-repository-using-svnsync/
http://whynotwiki.com/How_I_moved_my_code_repository_to_Google_Code。本节关于SVN库迁移和备份内容讲解完毕，请关注本节其他相关报道。

学习笔记如何使用svnsync命令对SVN库进行备份

本节向大家介绍一下如何使用svnsync命令对SVN库进行备份，使用svnsync备份很简单，只有四个步骤，在这里和大家简单介绍一下，希望通过本节的学习大家能够掌握使用svnsync命令对SVN库进行备份的方法。

下面是具体的备份步骤：
一、在备份机上创建一个空库：svnadmincreateSMP
二、更改该库的钩子脚本pre-revprop-change（因为svnsync要改这个库的属性，也就是要将源库的属性备份到这个库，所以要启用这个脚本）:
cdSMP/hooks;
cppre-revprop-change.tmplpre-revprop-change;
chmod755pre-revprop-change;
vipre-revprop-change;
将该脚本后面的三句注释掉，或者干脆将它弄成一个空文件。
三、初始化，此时还没有备份任何数据：
svnsyncinitfile:///home/backup/svn/svnsync/SMP/http://svntest.subversion.com/repos/SMP
语法是：svnsyncinit{你刚创建的库url}{源库url}
注意本地url是三个斜杠的：///
四、开始备份SVN库：
svnsyncsyncfile:///home/backup/svn/svnsync/SMP
这是就一个个版本进行备份了。我们来看一下SVN库备份过程中可能出现的错误。
附录：
可能的报错一：

Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
Failedtogetlockondestinationrepos,currentlyheldby'bug1.corp.scmbbs.com:0c424c20-2e3b-0410-bd34-7fdd53c25d02'
svnsync:Couldn'tgetlockondestinationreposafter10attempts

这个时候可能属性被锁了，删掉属性：svnpropdelsvn:sync-lock--revprop-r0file:///home/backup/svn/svnsync/SMP
删除成功后，再试一遍基本就可以了。如果反复操作都是同样错误的话，有可能是你的svn安装的有问题，重新安装一遍就好了，俺就是这样。
可能报错二、
svnsync:REPORTrequestfailedon'http://svn1.subversion.com/repos/Relevance'
svnsync:Therequestedreportisunknown.这是因为你源库的版本太低了，svnsync所需要的函数Report是svn1.4后加入的。没办法，对你的SVN库进行升级后才能备份。

本节向大家介绍一下如何使用SVN客户端和http协议访问SVN库问题，在学习SVN库的过程中这些问题你可能经常遇到，下面我们就来看一下如何访问SVN库，希望通过本节的学习大家能够掌握访问SVN库的方法。下面是具体的介绍。

使用SVN客户端访问SVN库
配置SVN服务器端:
首先,创建subversion用户组,并且将www-data和您自己这两个用户加入该组.(这可以通过在Ubuntu菜单上选择“系统->系统管理->用户和组”操作).
其次,创建svn的根位置,
$sudomkdir/home/svn
$cd/home/svn
然后,开始一个新的知识库,
$sudomkdirmyproject
$sudochown-Rroot:subversionmyproject//这里要给www-data添加权限，因为我们后面要用apache
$sudochmod-Rg+rwsmyproject//这个是为了赋予组成员对所有新加入文件仓库的文件拥有相应的权限
$sudosvnadmincreate/home/svn/myproject//开始一个新的知识库
最后,设置用户验证,
$sudovim/home/svn/myproject/conf/svnserve.conf//将#[general]和#password-db=passwd的注释取消掉,这表示使用同级目录下的passwd文件做为密码数据库.
$sudovim/home/svn/myproject/conf/passwd//添加admin用户及密码.
3.使用svn客户端:
这里只介绍两种方式,假设工作目录位于/home/cyndi/work/下.
$svncofile:///home/svn/myproject//这是当客户端与服务器端在同台机器上时,这么访问.
$svncosvn://10.28.158.133/home/svn/myproject–usernameadmin
另外,为了使客户端访问知识库时简化目录,可以在服务器端启用daemon,
$svnserve-d–foreground-r/home/svn
这样客户端的访问可以简化为,
$svncosvn://10.28.158.133/myproject–usernameadmin
详细的svn安装及设置可参考:http://wiki.ubuntu.org.cn/SubVersion
使用http协议访问SVN库
访问svn库的协议有三种：file,svn和http，其中file和svn的配置比较简单，首先使用svnadmincreate创建一个svn目录，然后使用svnserve-d-r启动该目录，就可以使用file和svn协议访问该svn库了。但是，如果要使用http协议访问svn库，需要做一些另外的配置。
首先要安装mod_dav_svn模块，然后修改httpd.conf文件，添加svn配置如下：

<Location/svn>
DAVsvn
SVNPath/Path/To/Svn
</Location>

这种配置是最简单的配置，没有涉及权限的问题，如果要为你的svn库添加访问权限，参考以下文档：http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html
注意对于你的svn目录/Path/To/Svn，一定要讲其权限改为apache用户，使用命令chown-Rapache:apache/Path/To/Svn，这样就可以使用http协议访问svn库了。
其次，在创建svn库时（svnadmincreate）,要使用其默认的文件格式（fsfs）保存版本信息，如果使用（dbd）格式的，svn库不稳定，容易出错。

SVN库的目录结构详解

本节和大家讨论一下SVN库的目录结构问题，这里我发表一下个人理解，和大家讨论讨论，欢迎大家一起来学习SVN库的目录结构方面的知识。
1、所有项目都在一个SVN库中么？
对于这个问题，个人认为，应该每个项目建一个SVN库，为什么这样说呢，因为SVN是全局版本，假如SVN库是如下结构：
SVN库<全局版本1.1>
┠项目A<1.1>
┖项目B<1.1>
这就会导致任何一个项目修改，影响全局版本修改，不能真实反映单个项目的版本情况。
2、SVN库的目录结构该怎样规划？
参考了国外一些主要的开发网站，如SourceForge，大同小异，类似这样的目录结构：
SVN库
┠tags(发布)
┃├1.1rc1
┃├1.2
┃├1.5
┃└1.9
┠trunk(主版本)
┃└project
┃├src
┃├classes
┃└WEB-INF
┖branches(分支)
└分支
主要的开发工作放在trunk，分支放在branches，发布版本放在tags。
存储库
┠项目名
┃├trunk：主版本
┃├branches：分支版本（独立版本）
┃└tags：标记版本，比如发行版v1.0/v2.0等等
3、SVN库的管理原则：
1、项目负责人和版本管理员负责架构项目目录结构，包括配置文件、第三方JAR文档
2、项目负责人分配开发人员目录权限，由版本管理员负责实施，权限分配粒度要细
3、trunk,tags,branches,项目负责人、协同版本管理员构建tags和branches
4、版本管理员负责解决开发人员在开发过程中的有关版本问题
5、开发人员每次修改，或者新增、删除、拷贝工作区对象后，应该立刻提交到版本库，有效保持工作区与资源库的高度一致，每天下班之前提交、（更新）
6、开发人员在每次修改工作区中代码或者文档时，首先更新该对象，可以尽量减少冲突、合并
7、保证提交到的版本库的代码没有BUG以免影响开发组，可以适当利用加锁机制，减少冲突
8、项目负责人和版本管理员负责软件的测试版，构建测试环境，branches由版本管理员进行（checkout）
9、项目负责人和版本管理员负责发布软件的发布版，与系统部协调构建发布环境(export)
10、版本管理员负责清理有关不需要的branches,tags。本节关于SVN库的目录结构讲解完毕。

揭开SVN冲突神秘面纱

本节讲解一下SVN冲突问题，随着SVN的快速发展，SVN可以再多个操作系统中搭建，这是难免会遇到SVN冲突问题，这些冲突如何解决，本文就为大家一一讲解。

1、如何产生SVN冲突
当开发人员A和开发人员B从版本库同时检出文档1.txt，而A和B同时修改了1.txt的同一地方，后提交的一方会在拷贝副本中产生冲突。
两个工作拷贝，A拷贝中文件1.txt内容为
dfqerq
123dfwre
B拷贝中文件1.txt内容为
dfqerq
123erwrq
在B版本提交之前版本库上的1.txt（base版本）内容为
dfqerq
B拷贝先提交版本到版本库中，以至于最新版本内容变为
dfqerq
123erwrq
此时A版本也提交则会产生冲突，无法提交，需要先svnupdate，此时会在A拷贝中产生三个临时文件1.txt.rNew\1.txt.rOld\1.txt.mine，其中1.txt.rNew是最新版本，1.txt.rOld是base版本，1.txt.mine是A作者修改后的版本，在此例中内容为
dfqerq
123dfwre
而update之后A拷贝中的1.txt内容为
<<<<<<<.mine
dfqerq
123dfwre=======
dfqerq
123erwrq>>>>>>>.r18
其中<<<<<<<.mine与=======之间表示A修改后的内容，=======与>>>>>>>.r18之间是版本服务器上的版本
2、解决SVN冲突
第一种，利用update的选项进行SVN冲突解决，也就是说不管当前拷贝副本是否是最新版本，都使用—accept参数作为冲突处理方式
--acceptARG:specifyautomaticconflictresolutionaction
('postpone','base','mine-conflict',
'theirs-conflict','mine-full','theirs-full',
'edit','launch')
(p)postpone-marktheconflicttoberesolvedlater//让文件在更新完成之后保持冲突状态。
(df)diff-full-showallchangesmadetomergedfile//使用标准区别格式显示base修订版本和冲突文件本身的区别。
(e)edit-changemergedfileinaneditor//用你喜欢的编辑器打开冲突的文件，编辑器是环境变量EDITOR设置的。
(r)resolved-acceptmergedversionoffile//完成文件编辑之后，通知svn你已经解决了文件的冲突，它必须接受当前的内容—从本质上讲就是你已经“解决了”冲突。
(mf)mine-full-acceptmyversionofentirefile(ignoretheirchange//丢弃新从服务器接收的变更，并只使用你查看文件的本地修改。
(tf)theirs-full-accepttheirversionofentirefile(losemychanges)//丢弃你对查看文件的本地修改，只使用从服务器新接收的变更。
(l)launch-launchexternaltooltoresolveconflict//启动一个外置程序来执行冲突解决，这需要一些预先的准备。
(h)help-showthislist//显示所有在冲突解决时可能使用的命令。
第二种，在update时并不处理SVN冲突，利用svnresolve解决冲突
1、利用svnresolve--acceptbase选择base版本，即1.txt.rOld作为最后提交的版本
--acceptARG:specifyautomaticconflictresolutionsource
('base','working','mine-conflict',
'theirs-conflict','mine-full','theirs-full')
2、手工修改1.txt文件，然后将当前拷贝即1.txt作为最后提交的版本
svnresolve--acceptworking1.txt
3、svnresolve--accepttheirs-full1.txt使用1.txt.rNew作为最后提交的版本
4、svnresolve--acceptmine-full1.txt使用1.txt.mine作为最后提交的版本
5、svnresolve--acceptmine-conflict1.txt使用1.txt.mine的冲突部分作为最后提交的版本
5、svnresolve--accepttheirs-conflict1.txt使用1.txt.rNew的冲突部分作为最后提交的版本。本节关于SVN冲突问题介绍完毕。

SVN目录结构组成深度剖析

本节向大家讲解一下SVN目录结构组成，之前几节我们学习了SVN库的目录结构相信大家应该掌握了，在这里和大家简单介绍一下SVN目录结构组成，欢迎大家一起来学习。

首先看一下下面的这个结构。

wolfwebadmin
├─ProjectManagement
│├─trunk
│├─branches
│└─tags
└─SSO
├─trunk
├─branches
└─tags
大概的说一下,ProjectManagement和SSO是两个项目trunk是开发的主线代码,存放能够运行的正确的代码;程序员如果开发新的程序或者改bug,一般要先branch(SVN的一个功能)trunk目录下的代码到branches目录的一个子目录,在那里对代码进行修改,确认无误后再提交到trunk主线下(但是有的时候为了效率,我们也多人都在trunk目录下开发项目).tags目录可以看做主线代码的快照,比如你做了1.0又做了2.0,那每个不同版本的代码你就做快照放到tags文件夹下了。

一个Subversion版本库实现了一种版本化的文件系统，版本库只是一个包含目录和文件的文件系统，而且它的文件系统是版本化的，并且实现了”廉价”拷贝，让它的这种操作比传统文件系统便宜很多，但是版本库本身还是像一个文件系统：Subversion本身没有特别的目录或名称用来代表trunk或branches，他们只是文件系统的普通目录，这依赖于你给这些目录名和结构的一种意义。也就是说，社区已经采纳了多种普通的布局作为最佳实践，因此一个人可以将其视为推荐方式。如果你的版本库是公共访问的，根据这些习惯，用户可以方便的访问版本库来查找他们所需要的。
有两种常见的SVN目录结构布局：
trunk
branches
tags
第一种布局是版本库包含一个项目或一组紧密联系项目的最佳选择，这个布局非常好用，因为分支与标签整个项目或一组项目会非常简单，只需要一个简单的命令：
svncopyurl://repos/trunkurl://repos/tags/tagname-m“Createtagname”
这可能是最常用的版本库布局，被许多开源项目采用，就像Subversion本身和Subclipse，这是大多数主机站点，如Tigris.org,SourceForge.net和GoogleCode遵循的方法，这些站点的每个项目有自己的版本库。
另一种SVN目录结构布局是针对一个版本库包含不相关项目的最佳选择。
ProjectA
trunk
branches
tags
ProjectB
trunk
branches
tags
在这种布局里，每个项目会存在顶级目录里，然后该目录之下创建trunk/branches/tags，其中与第一种布局相同，这只是将项目放到自己版本库方式的替换，他们都在一个版本库中。Apache软件基金会使用这种布局方式来存放他们的所有项目在一个版本库。
通过这种布局，每个项目都有自己的分支和标签，可以很容易使用一个命令创建分支和标签，就像前面展示的：
svncopyurl://repos/ProjectA/trunkurl://repos/ProjectA/tags/tagname-m“Createtagname”
这种布局可以简单的创建同时包含ProjectA和ProjectB的标签，你可以这样做，但是需要多个命令，你也要决定是否创建一个特别的目录存放这种分支和标签，如果你需要经常这样做，你或许应该考虑第一种SVN目录结构布局。

至于版本库中目录的名称，再说一遍：只是一种习惯，他们在Subversion中没有特别含义。
“trunk”可以认为是项目的开发主线，你可以称之为“main”，”mainline”，”production”或任何你喜欢的名字。
“branches”是放置分支的地方，人们因各种目的使用分支，你或许希望通过特性分支或客户修改分支来隔离你的发布或维护分支等，在这个例子里，你可以在branches创建一层目录，或只是在顶级目录创建多个分支目录。

“tags”也不会被Subversion特别对待，他们只是习惯，或许通过钩子脚本或授权规则进行强制，来指明你创建了一个时间点的快照，通常情况下tags与分支的区别就是tags一旦创建不能修改，你也可以将标签目录叫做”releases”，”snapshots”，”baselines”或任何你喜欢的。
记住，名称对你有意义，不是Subversion。最后，Subversion的架构，全局修订版本经常使得标签没有必要，我不知道只是因为要创建tag而创建tag有什么意义，如果你需要在特定时间点重建软件，你可以通过svnlog来确定相关的修订版本号。tags对于版本库的”外部”用户很有用，或许QA/Release团队需要执行构建，或许是一个内部开发小组希望在另一个产品使用发布版本，或是外部用户或客户希望根据字面含义从版本库获取发布快照，在这些场景中，创建tag是保证获取正确代码的最简单方法，也需要有好的交流机制来指明发布快照。

希望本文可以为你澄清一些问题，让你更好的理解Subversion是如何工作的。最后，我希望指出Subversion版本库的布局是可以修改的，你可以一直重组和重构布局，最坏情况下，会让用户调整他们的工作拷贝，但不会让你从头再来，你应该自由的改名，移动目录或任何你希望改变版本库的方式去做。本节关于SVN目录结构讲解完毕，请关注本节其他相关报道。

SVN冲突解决方法名师介绍

本节向大家讲解一下SVN冲突的解决方法，在这里和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，欢迎打击一起来学习SVN冲突方面的知识。
本人使用SVN的时间不是很长，在使用之前也仅仅是粗浅的了解过这个软件。从今年的8月份开始，由于一个项目使用Eclipse3.1，跨地域的开发，为了适应不同的开发人员处于不同的地理位置，因此我们使用SVN作为团队开发的管理工具。开始使用时，仅仅是边学边用，遇到不懂的地方再去查找资料。今天由于有点时间，先把合并过程遇到的冲突问题详细了解一下。
可以使用svnstatus-u命令来查看一下某个问题是否会有冲突发生。在使用svnupdate的时候，会出现如下一些信息：
$svnupdate
UINSTALL
GREADME
Cbar.c
Updatedtorevision46.
那么，U开头的信息提示你，这个文件在你本地没有修改过，文件已经根据版本库的新版本更新了。G开头的信息提示你，这个文件在你本地已经修改过，但是和版本库中对应的版本并没有冲突的地方，svn已经合并更新了。而C开头的信息提示你，这个文件有点麻烦，你在本地的修改和版本库中的版本修改的地方重叠了，也就是说，你修改了某一行，你的同事也修改了同一行。这个就需要你自己手工去解决了。当冲突发生时，要注意到有三件事情可以帮助你解决问题。
a.Subversion会给这个文件作出c标记。
b.如果Subversion认为这个文件时可以合并的，它会一个冲突标记（特殊的横线来分开冲突的代码块）
c.对每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作拷贝。
filename.mine
你更新前的文件，没有SVN冲突标志，只是你最新更改的内容。（如果这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同。）
filename.rOLDREV
这个是你做更新操作以前的BASE版本，就是你在上次更新之后未作更改的版本。
filename.rNEWREV
这是Subversion从服务器刚刚收到的版本。这个版本就是版本库的HEAD版本。
例如，如果sally修改了一个文件sandwich.txt,而harry也刚刚修改了这个文件的相同位置并提交到服务器。那么sally在做这个文件的update操作的时候会得到三个额外的文件sandwich.txt.mine、sandwich.txt.r1、sandwich.txt.r2。并且在提交的时候会遭到服务器的拒绝，因为这个文件的冲突问题还没有得到解决。要解决这个冲突，可以选择：
a.手工合并SVN冲突文件（检查和修改文件中的冲突标志）。
b.用一个临时文件（三个中的一个）覆盖你的工作文件。
c.运行svnrevert<filename>来放弃所有的修改。
一旦解决了你的冲突，需要通过命令svnresolved让subversion知道并删除三个临时文件。这时才可以提交。
下面再说说手工合并SVN冲突。开始的时候让人觉得害怕，但做一段时间之后，就觉得不那么烦人了。
看看如下文本：
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
GrilledChicken
>>>>>>>.r2
CreoleMustard一连串的大于、小于、等于号是SVN冲突标记，这些数据得全部删除才可以提交。其中,
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======是你在冲突区里面做的修改。
Sauerkraut
GrilledChicken
>>>>>>>.r2
是别人在冲突区做的修改。
在SVN冲突区中，或许你需要和你的同事沟通来安排冲突区的文本内容，如果是程序代码，你需要和同事商量一下，中间的这段代码到底应该是什么样子的。
所有冲突区得到合理的解决之后，你就可以提交你的文件了。

SVN冲突解决方法大全

本节向大家介绍一下SVN冲突解决和winmerge使用手册问题，在学习SVN的过程中，难免会遇到SVN冲突问题，于是和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西。
解决版本冲突的命令。在冲突解决之后，需要使用svnresolved来告诉subversion冲突解决，这样才能提交更新。冲突发生时，subversion会在WorkCopy中保存所有的目标文件版本（上次更新版本、当前获取的版本，即别人提交的版本、自己更新的版本、目标文件。假设文件名是sandwich.txt，对应的文件名分别是：sandwich.txt.r1、sandwich.txt.r2、sandwich.txt.mine、sandwich.txt）。同时在目标文件中标记来自不同用户的更改。
解决SVN冲突的办法：
-手动解决：冲突发生时，通过和其他用户沟通之后，手动更新目标文件。然后执行svnresolvedfilename来解除冲突，最后提交。
-放弃自己的更新，使用别人的更新。使用最新获取的版本覆盖目标文件，执行svnresolvedfilename并提交。
-放弃自己的更新，使用svnrevert，然后提交。在这种方式下不需要使用svnresolved。
对于svnresolved命令需要非常小心，必须是非常确定冲突已经解决才能使用。否则，会导致Subversion以为冲突解决，而使代码库不正确。
解决冲突详细文档:http://svnbook.subversion.org.cn/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve
解决冲突（合并别人的修改）
我们可以使用svnstatus-u来预测冲突，当你运行svnupdate一些有趣的事情发生了：
$svnupdate
UINSTALL
GREADME
Cbar.c
Updatedtorevision46.
U和G没必要关心，文件干净的接受了版本库的变化，文件标示为U表明本地没有修改，文件已经根据版本库更新。G标示合并，标示本地已经修改过，与版本库没有重迭的地方，已经合并。
但是C表示冲突，说明服务器上的改动同你的改动冲突了，你需要自己手工去解决。当冲突发生了，有三件事可以帮助你注意到这种情况和解决问题：
Subversion打印C标记，并且标记这个文件已冲突。
如果Subversion认为这个文件是可合并的，它会置入SVN冲突标记—特殊的横线分开冲突的“两面”—在文件里可视化的描述重叠的部分（Subversion使用svn:mime-type属性来决定一个文件是否可以使用上下文的，以行为基础合并，更多信息可以看“svn:mime-type”一节）。
对于每一个冲突的文件，Subversion放置三个额外的未版本化文件到你的工作拷贝：filename.mine
你更新前的文件，没有冲突标志，只是你最新更改的内容。（如果Subversion认为这个文件不可以合并，.mine文件不会创建，因为它和工作文件相同。）
filename.rOLDREV这是你的做更新操作以前的BASE版本文件，就是你在上次更新之后未作更改的版本。
filename.rNEWREV这是你的Subversion客户端从服务器刚刚收到的版本，这个文件对应版本库的HEAD版本。
这里OLDREV是你的.svn目录中的修订版本号，NEWREV是版本库中HEAD的版本号。
举一个例子，Sally修改了sandwich.txt，Harry刚刚改变了他的本地拷贝中的这个文件并且提交到服务器，Sally在提交之前更新它的工作拷贝得到了冲突：
$svnupdate
Csandwich.txt
Updatedtorevision2.
$ls-1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2
在这种情况下，Subversion不会允许你提交sandwich.txt，直到你的三个临时文件被删掉。
$svncommit--message"Addafewmorethings"
svn:Commitfailed(detailsfollow):
svn:Abortingcommit:'/home/sally/svn-work/sandwich.txt'remainsinconflict
如果你遇到SVN冲突，三件事你可以选择：
“手动”合并冲突文本（检查和修改文件中的冲突标志）。
用某一个临时文件覆盖你的工作文件。
运行svnrevert<filename>来放弃所有的修改。
一旦你解决了冲突，你需要通过命令svnresolved让Subversion知道，这样就会删除三个临时文件，Subversion就不会认为这个文件是在冲突状态了。
[5]$svnresolvedsandwich.txt
Resolvedconflictedstateof'sandwich.txt'
手工合并SVN冲突
第一次尝试解决冲突让人感觉很害怕，但经过一点训练，它简单的像是骑着车子下坡。
这里一个简单的例子，由于不良的交流，你和同事Sally，同时编辑了sandwich.txt。Sally提交了修改，当你准备更新你的版本，冲突发生了，我们不得不去修改sandwich.txt来解决这个问题。首先，看一下这个文件：
$catsandwich.txt
Toppieceofbread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<<.mine
Salami
Mortadella
Prosciutto
=======Sauerkraut
GrilledChicken
>>>>>>>.r2
CreoleMustard
Bottompieceofbread
小于号、等于号和大于号串是冲突标记，并不是冲突的数据，你一定要确定这些内容在下次提交之前得到删除，前两组标志中间的内容是你在SVN冲突区所做的修改：
<<<<<<<.mine
Salami
Mortadella
Prosciutto=======
后两组之间的是Sally提交的修改冲突：
=======Sauerkraut
GrilledChicken
>>>>>>>.r2
通常你并不希望只是删除SVN冲突标志和Sally的修改。

SVN冲突问题专家详解

上节我们讲到SVN冲突解决方法中手动合并冲突，本节接着上节继续介绍SVN冲突解决方法，这里我发表一下个人理解，和大家讨论讨论，希望对你的学习有所帮助。下面是具体介绍。

[6]一旦你们确认了提交内容后，修改文件并且删除冲突标志。
Toppieceofbread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
CreoleMustard
Bottompieceofbread
现在运行svnresolved，你已经准备好提交了：
$svnresolvedsandwich.txt
$svncommit-m"Goaheadandusemysandwich,discardingSally'sedits."
记住，如果你修改SVN冲突时感到混乱，你可以参考subversion生成的三个文件—包括你未作更新的文件。你也可以使用第三方的合并工具检验这三个文件。
拷贝覆盖你的工作文件
如果你只是希望取消你的修改，你可以仅仅拷贝Subversion为你生成的文件替换你的工作拷贝：
$svnupdate
Csandwich.txt
Updatedtorevision2.
$lssandwich.*
sandwich.txtsandwich.txt.minesandwich.txt.r2sandwich.txt.r1
$cpsandwich.txt.r2sandwich.txt
$svnresolvedsandwich.txt
下注：使用svnrevert
如果你得到上SN冲突，经过检查你决定取消自己的修改并且重新编辑，你可以恢复你的修改：
$svnrevertsandwich.txt
Reverted'sandwich.txt'
$lssandwich.*
sandwich.txt
注意，当你恢复一个冲突的文件时，不需要再运行svnresolved。
现在我们准备好提交修改了，注意svnresolved不像我们本章学过的其他命令一样需要参数，在任何你认为解决了SVN冲突的时候，只需要小心运行svnresolved，—一旦删除了临时文件，Subversion会让你提交这文件，即使文件中还存在冲突标记。
提交你的修改
最后！你的修改结束了，你合并了服务器上所有的修改，你准备好提交修改到版本库。
svncommit命令发送所有的修改到版本库，当你提交修改时，你需要提供一些描述修改的日志信息，你的信息会附到这个修订版本上，如果信息很简短，你可以在命令行中使用--message（-m）选项：
$svncommit--message"Correctednumberofcheeseslices."
Sendingsandwich.txt
Transmittingfiledata.
Committedrevision3.
然而，如果你把写日志信息当作工作的一部分，你也许会希望通过告诉Subversion一个文件名得到日志信息，使用--file选项：
$svncommit--filelogmsg
Sendingsandwich.txt
Transmittingfiledata.
Committedrevision4.
如果你没有指定--message或者--file选项，Subversion会自动地启动你最喜欢的编辑器（见“config”一节的editor-cmd部分）来编辑日志信息。
提示
如果你使用编辑器撰写日志信息时希望取消提交，你可以直接关掉编辑器，不要保存，如果你已经做过保存，只要简单的删掉所有的文本并再次保存。
$svncommit
WaitingforEmacs...Done
Logmessageunchangedornotspecified
a)bort,c)ontinue,e)dit
a$
版本库不知道也不关心你的修改作为一个整体是否有意义，它只检查是否有其他人修改了同一个文件，如果别人已经这样做了，你的整个提交会失败，并且提示你一个或多个文件已经过时了：
$svncommit--message"Addanotherrule"
Sendingrules.txt
svn:Commitfailed(detailsfollow):
svn:Outofdate:'rules.txt'intransaction'g'
此刻，你需要运行svnupdate来处理所有的合并和SVN冲突，然后再尝试提交。
我们已经覆盖了Subversion基本的工作周期，还有许多其它特性可以管理你得版本库和工作拷贝，但是只使用前面介绍的命令你就可以很轻松的工作了。
[3]当然没有任何东西是在版本库里被删除了—只是在版本库的HEAD里消失了，你可以通过检出（或者更新你的工作拷贝）你做出删除操作的前一个修订版本来找回所有的东西。
[4]Subversion使用内置区别引擎，缺省情况下输出为统一区别格式。如果你期望不同的输出格式，你可以使用--diff-cmd指定外置的区别程序，并且通过--extensions传递其他参数，举个例子，察看本地文件foo.c的区别，同时忽略空格修改，你可以运行svndiff--diff-cmd/usr/bin/diff--extensions'-bc'foo.c。
[5]你也可以手工的删除这三个临时文件，但是当Subversion会给你做时你会自己去做吗？我们是这样想的。
[6]如果你向他们询问，他们非常有理由把你带到城外的铁轨上。
如何降低SVN冲突解决的复杂度:
-当工作完成之后（即编写完程序，单元测试通过）尽快的提交，频繁的提交/更新可以降低在冲突发生的概率，以及发生时解决冲突的复杂度。
-如果冲突频繁发生，就有必要找出原因了。
-在提交时，书写明确的message。方便以后的查找更新的原因，毕竟随着时光流逝，记忆也会变得模糊。本节讲解SVN冲突完毕。

本节和大家一起学习一下SVN文件冲突和树冲突，主要包括SVN文件冲突和树冲突如何出现，以及怎样解决这些冲突，希望通过本文的学习大家能够掌握住这些方法。
解决冲突
偶尔，当你从版本库更新、合并文件时，或者切换工作副本至一个不同的URL时你会遇到冲突。有两种冲突:
SVN文件冲突
当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。
SVN树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。
SVN文件冲突
当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于Subversion不知道你的项目的具体情况，它把解决冲突的工作留给了开发人员。一旦出现冲突，你就应该打开有问题的文件，查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记:
<<<<<<<文件名你的修改=======合并自版本库中的代码>>>>>>>版本
对于每个冲突的文件Subversion在你的目录下放置了三个文件:
文件名.ext.mine
这是你的文件，在你更新你的工作副本之前存在于你的的工作副本中——也就是说，没有冲突标志。这个文件除了你的最新修改外没有别的东西。
文件名.ext.r旧版本
这是在你更新你的工作副本之前的基础版本(BASErevision)文件。也就是说，它是在你做最后修改之前所检出的文件。
文件名.ext.r新版本
这个文件是当你更新你的工作副本时，你的Subversion客户端从服务器接收到的。这个文件对应于版本库中的最新版本。
你可以通过TortoiseSVN→编辑冲突运行外部合并工具/冲突编辑器，或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的，做一些必要的修改然后保存。
然后，执行命令TortoiseSVN→已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突，它只是删除了filename.ext.mine和filename.ext.r*两个文件，允许你提交修改。
如果你有二进制SVN文件冲突，Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子)，但你会看到filename.ext.r*文件。如果你要撤消你的修改，保留版本库中的版本，请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本，使用已解决命令，然后提交你的版本。
你可以右击父文件夹，选择TortoiseSVN→已解决...，使用“已解决”命令来解决多个文件。这个操作会出现一个对话框，列出文件夹下所有有冲突的文件，你可以选择将哪些标记成已解决。
树冲突
当一名开发人员移动、重命名、删除一个文件或文件夹，而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多种不同的情形可以导致树冲突，而且不同的情形需要不同的步骤来解决冲突。
当一个文件通过Subversion在本机删除后，文件也从本机文件系统中删除。因此即使它是树冲突的一部分，却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。
TortoiseSVN能够协助找到合并更改的正确位置，但是需要作一些额外的工作来整理冲突。请牢记:当进行一次更新操作后，工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改，工作副本将返回到版本库的状态，而不是你开始进行更改前的状态。
本地删除，当更新时有更改进入开发人员A修改Foo.c并将其提交至版本库中
开发人员B同时在他的工作副本中将文件Foo.c改名为Bar.c，或者仅仅是删除了Foo.c或它的父文件夹。
更新开发人员B的工作副本会导致树冲突:
在工作副本中，Foo.c被删除了，但是被标记为树冲突。
如果冲突是由于更改文件名引起的而不是删除文件引起的，那么Bar.c被标记为添加，但是其中却不包括开发人员A修改的内容。
开发人员B现在必须做出选择是否保留开发人员A的更改。在更改文件名的案例中，他可以将Foo.c的更改合并到改名后的文件Bar.c中去。对于删除文件或文件夹的案例中，他可以选择保留包含开发人员A更改内容的项目并放弃删除操作。或什么也不做而直接将冲突标记为已解决，那样他实际上丢弃了开发人员A的更改。
如果TortoiseSVN能够找到被改名为Bar.c的原始文件，冲突编辑对话框将可以合并更改。这取决于在什么地方调用更新操作，它也许不能找到原始文件。
本地更改，当更新时有删除进入开发人员A将文件Foo.c改名为Bar.c并将其提交至版本库中。
开发人员B在他的工作副本中修改文件Foo.c。或者在一个文件夹改名的案例中...
开发人员A将父文件夹FooFolder改名为BarFolder并将其提交至版本库中。
开发人员B在他的工作副本中修改文件Foo.c。
更新开发人员B的工作副本会导致树冲突。对于一个简单的SVN文件冲突:
Bar.c被当作一个正常文件添加到工作副本中。
Foo.c被标记为添加(包括其历史记录)并且产生树冲突。
对于一个文件夹冲突:
BarFolder被当作一个正常文件夹添加到工作副本中。
FooFolder被标记为添加(包括其历史记录)并且产生树冲突。
Foo.c被标记为已修改。
开发人员B现在需要做出决定是否接受开发人员A作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员A的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员B认为A的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员A的更改。又是通过日志对话框帮助追踪哪些文件移动了。请期待下节SVN文件冲突和树冲突问题讲解。

本节简单介绍一下SVN文件冲突和SVN树冲突在本地的解决方法，在这里和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，让我们一起来学习SVN文件冲突和SVN树冲突的解决方法吧。

1.本地删除，当更新时有删除进入开发人员A将文件Foo.c改名为Bar.c并将其提交至版本库中。
开发人员B将文件Foo.c改名为Bix.c
更新开发人员B的工作副本会导致树冲突:
Bix.c被标记为添加(包括其历史记录)。
Bar.c被添加到工作副本中，其状态为‘正常’。
Foo.c被标记为删除并且产生一个SVN树冲突。
要解决这个冲突，开发人员B必须找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以使用日志对话框来完成这个任务。
然后，开发人员B需要决定Foo.c的新文件名中的哪一个需要保留-开发人员A改的那个还是他自己改的那个。
在开发人员B手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。
本地缺少，当合并时有更改进入开发人员A在主干上工作，修改Foo.c并将其提交至版本库中
开发人员B在分支上工作，将Foo.c改名为Bar.c并将其提交至版本库中
合并开发人员A的主干更改到开发人员B的分支工作副本会导致SVN树冲突:
Bar.c已经存在于工作副本中，其状态为‘正常’。
Foo.c被标记为缺少并产生SVN树冲突。
要解决这个冲突，开发人员B要在冲突编辑对话框中标记文件为已解决，这样就会将其从冲突列表中删除。她接下来需要决定是否将缺少的文件Foo.c从版本库中复制到工作副本中，是否将开发人员A的对Foo.c的更改和合并到改名后的Bar.c或者是否通过标记冲突为已解决来忽略更改什么事也不做。
注意，如果你将缺少的文件从版本库中复制到工作副本中然后再标记为已解决，你复制下来的文件将被再次删除。你必须先解决冲突。

2.本地更改，当合并时有删除进入开发人员A在主干上工作，将Foo.c改名为Bar.c并将其提交至版本库中
开发人员B在分支上工作，修改Foo.c并将其提交至版本库中
当文件夹改名时有类似的案例，但是在Subversion1.6中还未被识别...
开发人员A在主干上工作，将父文件夹FooFolder改名为BarFolder并将其提交至版本库中。
开发人员B在分支上工作，在她的工作副本中修改Foo.c。
合并开发人员A的主干更改到开发人员B的分支工作副本会导致SVN树冲突:
Bar.c被标记为添加。
Foo.c被标记为修改并产生SVN树冲突。
开发人员B现在需要做出决定是否接受开发人员A作出的结构改变并且合并她的更改到新结构下适当的文件中，或者直接放弃开发人员A的更改并保留本地文件。
要合并她的本机更改到新布局中，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。更改必须要手工合并，因为没有办法自动的或者简单的完成此操作。一旦更改移植完毕，冲突的路径就是多余的并且可以删除。在此案例中，使用冲突编辑对话框中的删除按钮进行清理并将冲突标记为已解决。
如果开发人员B认为A的更改是错误的，那么在冲突编辑对话框中她必须选择保留按钮。这样就会标记冲突的文件/文件夹为已解决，但是需要手工删除开发人员A的更改。又是通过日志对话框帮助追踪哪些文件移动了。
本地删除，当合并时有删除进入开发人员A在主干上工作，将Foo.c改名为Bar.c并将其提交至版本库中
开发人员B工作在分之上，将Foo.c改名为Bix.c并将其提交至版本库中

3.合并开发人员A的主干更改到开发人员B的分支工作副本会导致SVN树冲突:
Bix.c被标记为正常(未修改)状态。
Bar.c被标记为添加(包括其历史记录)。
Foo.c被标记为缺少并且产生树冲突。
要解决这个冲突，开发人员B必须先找出冲突的文件Foo.c经过改名/移动后在版本库中的新文件名是什么。可以通过适用于合并源码的日志对话框来完成这个任务。冲突编辑器仅显示工作副本的日志因为它不知道将哪个路径的更改合并进来，所以你需要自己找到它。
然后，开发人员B需要决定Foo.c的新文件名中的哪一个需要保留-开发人员A改的那个还是他自己改的那个。
在开发人员B手工解决冲突后，使用冲突编辑对话框中的按钮将树冲突标记为已解决。本节关于SVN文件冲突和SVN树冲突内容讲解完毕，请关注本节其他相关报道。

本节和大家一起学习一下SVN文档的要点，在学习SVN的过程中你可能会遇到SVN问题，于是和大家分享一下，看完本文你肯定有不少收获，希望本文能教会你更多东西，欢迎打击一起来学习SVN文档方面的知识。
1.Subversion可以告诉我们工作文件是处于如下四种状态的那一种：
SVN文档未修改且是当前的
文件在工作目录里没有修改，在工作修订版本之后没有修改提交到版本库。svncommit操作不做任何事情，svnupdate不做任何事情。
本地已修改且是当前的
在工作目录已经修改，从基本修订版本之后没有修改提交到版本库。本地修改没有提交，因此svncommit会成功提交，svnupdate不做任何事情。
SVN文档未修改且不是当前的了
这个文件在工作目录没有修改，但在版本库中已经修改了。这个文件最终将更新到最新版本，成为当时的公共修订版本。svncommit不做任何事情，svnupdate将会取得最新的版本到工作拷贝。
SVN文档本地已修改且不是最新的
这个文件在工作目录和版本库都得到修改。一个svncommit将会失败，这个文件必须首先更新，svnupdate命令会合并公共和本地修改，如果Subversion不可以自动完成，将会让用户解决冲突。
这看起来需要记录很多事情，但是svnstatus命令可以告诉你工作拷贝中文件的状态，关于此命令更多的信息，请看“查看你的修改概况”一节
2.混合修订版本的工作拷贝
作为一个普遍原理，Subversion努力做到尽可能的灵活，一个特殊的灵活特性就是让工作拷贝包含不同工作修订版本的文件和目录，不幸的是，这个灵活性会让许多新用户感到迷惑。如果上一个混合修订版本的例子让你感到困惑，这里是一个为何有这种特性和如何利用这个特性的基础介绍。
SVN文档更新和提交是分开的
Subversion有一个基本原则就是一个“推”动作不会导致“拉”，反之亦然，因为你准备好了提交你的修改并不意味着你已经准备好了从其他人那里接受修改。如果你的新的修改还在进行，svnupdate将会优雅的合并版本库的修改到你的工作拷贝，而不会强迫将修改发布。
这个规则的主要副作用就是工作拷贝需要记录额外的信息来追踪混合修订版本，并且也需要能容忍这种混合，当目录本身也是版本化的时候情况更加复杂。
举个例子，假定你有一个工作拷贝，修订版本号是10。你修改了foo.html，然后执行svncommit，在版本库里创建了修订版本15。当成功提交之后，许多用户希望工作拷贝完全变成修订版本15，但是事实并非如此。修订版本从10到15会发生任何修改，可是客户端在运行svnupdate之前不知道版本库发生了怎样的改变，svncommit不会拖出任何新的修改。另一方面，如果svncommit会自动下载最新的修改，可以使得整个工作拷贝成为修订版本15—但是，那样我们会打破“push”和“pull”完全分开的原则。因此，Subversion客户端最安全的方式是标记一个文件—foo.html—为修订版本15，工作拷贝余下的部分还是修订版本10。只有运行svnupdate才会下载最新的修改，整个工作拷贝被标记为修订版本15。本节关于SVN文档方面的知识讲解完毕。

本节向大家简单介绍一下SVN配置文档，在这里提醒一下SVN和Apache的版本要对应起来，不然架设不起来，欢迎大家一起来学习SVN配置文档。下面是具体的介绍。
安装需要的软件包：
Apr：APR-1.2.12和APR-util-1.2.12
Apache：httpd-2.2.6.tar.gz
Subversion：subversion-1.4.5.tar.gzsubversion-deps-1.4.5.tar.gz
1、安装APR-1.2.12和APR-util-1.2.12
1)#tarzxvfapr-1.2.12.tar.gz
#cdapr-1.2.12
#./configure
Make;makeinstall
2)#tarzxvfapr-util-1.2.12.tar.gz
#cdapr-util-1.2.12
#./configure--with-apr=/usr/local/apr
#make;makeinstall。下面我们看一下SVN配置文档中安装Apache的介绍。
2、安装apache2.2.6
1）解包httpd-2.2.6.tar.gz
#tarxzvfhttpd-2.2.6.tar.gz
2)生成配置文件
#./configure--prefix=/usr/local/apache2--enable-dav--enable-modules=so--enable-maintainer-mode--enable-rewrite--with-apr=/usr/local/apr/bin/apr-1-config--with-apr-util=/usr/local/apr/bin/apu-1-config
3）生成make文件，并安装
#make；makeinstall
4）编辑配置文件httpd.conf
#vi/usr/local/apache2/conf/httpd.conf
（没修改）
保存退出
5）启动Apache服务：
#/usr/local/apache2/bin/apachectlstart
6）浏览网站：
用浏览器查看http://localhost/,得到itworks，说明apache已经配置成功了。
7）停止Apache服务：
#/usr/local/apache2/bin/apachectlstop
8）设置启动系统后，自启动Apache服务
编辑etc/rc.d/rc.local
#vi/etc/rc.d/rc.local
在最后加上一句：/usr/local/apache2/bin/apachectlstart
3、安装subversion
1）解包
SVN配置文档介绍安装SVN时首先要对下载的软件包进行解包。#tarxvzfsubversion-1.4.5.tar.gz
#tarxvzfsubversion-deps-1.4.5.tar.gz
2）转入解包目录并生成配置文件
#cdsubversion-1.4.5
SVN依赖的APR版本要正确。如果Apache为2.0.x，对应的APR版本应为0.9.x；Apache为2.2.x，对应的APR版本应为1.2.x。由于subversion-deps包里的APR是0.9.x的，因此编译svn时要删除从deps里解压出来的apr,apr-util，改而使用apache2.2里提供的。（这里指定为开始安装的apr目录）
如果apache不是安装在默认路径，configure必須加上--with-apxs选项,如：./configure--with-apxs=/usr/local/apache2/bin/apxs(此目录为我的apache安装目录)
#rm-rfapr
#rm-rfapr-util
#./configure--with-apxs=/usr/local/apache2/bin/apxs--prefix=/usr/local/subversion--with-apr=/usr/local/apr/bin/apr-1-config--with-apr-util=/usr/local/apr/bin/apu-1-config--with-ssl--with-zlib--enable-maintainer-mode
3）编译安装
#make；makeinstall
4）查看subversion两个动态库有没有安装成功
#vi/usr/local/apache2/conf/httpd.conf
看到下面两个模块说明安装成功
LoadModuledav_svn_modulemodules/mod_dav_svn.so
LoadModuleauthz_svn_modulemodules/mod_authz_svn.so。请期待下节关于SVN配置文档讲解。

posted on 2012-03-17 09:43 pengyingh 阅读(2670) 评论(0) 编辑收藏举报

刷新页面返回顶部

pengyingh

xcode 4 with subversion SVN server–Tips

First Contact

Thoughts

配置Xcode SVN从零开始

导航

公告