项目管理Redmine和版本跟踪SVN的完美结合

项目管理Redmine和版本跟踪SVN的完美结合
项目管理Redmine和版本跟踪SVN的完美结合

项目管理Redmine和版本跟踪SVN的完美结合

本节主要讲解一下项目管理和版本跟踪——Redmine和SVN的结合,Redmine 是项目管理,SVN是版本控制工具,那么怎样把他们结合一起以及结合时有哪些问题呢,下面本文就给你一一解答。

工作越来越繁琐,事情多了很多细节都会照顾不到,所以这次使用Redmine对项目进行安排和跟踪进度,又因为一直用SVN进行版本的管理,而且这两个系统是可以结合在一起使用,很容易看清楚每个人的代码、文档的变化。但是在安装和配置的时候却遇到不少小问题(在没有解决的时候就是天大的问题了),记录一下利人利已!

Redmine和SVN的结合,首先安装Ruby,Ruby是一键式安装,只要Next就行了。安装完成后,在CMD命令行下执行gem install rails --include-dependencies,执行这个命令的时候需要联网的,因为需要下载一些文件,而且过程有点慢,耐心等待其自动安装完成。

Redmine和SVN的结合时要下载Redmine,解压即可。在配置前,必须安装MySql 数据库,然后执行以下几个步骤:

1.在mysql中新建"redmine"数据库create database redmine character set utf8;

2.把config/database.yml.example更名为config/database.yml,并设置数据库用户名和密码

3.在命令提示符中到redmine的目录下,创建数据库结构rake db:migrate

RAILS_ENV="production"

4.安装默认配置 rake redmine:load_default_data RAILS_ENV="production"

5.运行服务器ruby script/server -e production,使用http://localhost:3000/进行浏览

6.使用admin/admin进行登陆。

Redmine和SVN的结合中在配置Redmine和SVN关联时需要注意几个问题:

1、系统变量Path中必须包含SVN的bin目录,如果你的SVN不在Redmine这机器上,需要另外安装SVN。有时候安装后SVN的bin目录不会自动加入到Path变量中,这时候需要手工加入;

2、客户端TortoiseSVN安装最新版本的,原因安装旧版本的TortoiseSVN时无法查看SVN的信息,这个不太明白,因为HTTP是可以访问的,理论上不需要TortoiseSVN都是可以的,这个试验没有试过;

3、卡巴斯基会与SVN冲突,解决的办法是在“设置”->"服务"->"网络设置"->"端口设置中取消对80端口的监控。Redmine和SVN的结合讲解完毕。

解决版本冲突问题的方法—分支与合并

解决版本冲突-使用SVN主干与分支功能 1前言 大多数产品开发存在这样一个生命周期:编码、测试、发布,然后不断重复。通常是这样的开发步骤: 1) 开发人员开发完毕某一版本(如版本A)功能后,提交测试; 2) 测试人员对待发布版本A进行测试,同时开发人员继续开发新功能(如版本B); 3) 测试人员提交bug,研发人员修复bug,同时继续开发新功能; 4) 重复第3步骤,直到待发布版本A测试通过测试后,发布第一版本 这样就会存在以下问题: 1) 如何从代码库中(A+B)分离出待发布版本A,进行测试和发布; 2) 如果单独存放待发布版本A,那么开发组必须同时维护此版本库A以及当前最新代码库 (A+B),操作冗余且容易出错。 在SVN中,通常采用主干(trunk)与分支(branches)的方法,解决以上问题。 2相关概念和原理 在SVN中创建代码库时,通常会创建trunk、branches、tags三个子目录,当然,你也可以用其他名称来实现主干和分支的功能 trunk-主干,或称主线,顾名思义,是开发的主线。 branches-分支,是从主线上分出来,独立于主线的另一条线。可以创建多个分支。一个分支 总是从主干一个备份开始的,从那里开始,发展自己独有的历史(如下图所示)。在版本控制的 系统中,我们经常需要对开发周期中的单独生命线作单独的修改,这条单独的开发生命线就可 以称为Branches,即分支。分支经常用于添加新的功能以及产品发布后的bug修复等,这样 可以不影响主要的产品开发线以及避免编译错误等。当我们添加的新功能完成后可以将其合并 到主干中。 tags-标记,主要用于项目开发中的里程碑,比如开发到一定阶段可以单独一个版本作为发布 等,它往往代表一个可以固定的完整的版本。即主干和分支都是用来进行开发,而标记是用来 进行阶段发布的。安全公司的配置库有专门的发布区,所以tags并不需要创建,在这里只是 提供说明,不推荐使用。 branches以及tags在TortoiseSVN中创建方法是一致的,它们都是通过存储类似Linux中的lunch 快捷方式一样,只是创建了指向某个版本的链接,而不会真正将此版本的内容复制到分支或者标记中,这样既可以节省空间,也可以很快速的创建,被称为“廉价的拷贝”。 为了便于创建分支和标记,通常习惯于将Repository版本库的结构布置为:/branches,/tags,/trunk。 分别代表分支,标记以及主干。

svn中解决代码冲突

解决代码冲突 如果commit时出现“You have to update your work copy first.”红色警告,说明版本库中的此文件已经被其他人修改了。请先点“ok”按钮退出。执行update,然后再commit。 如果修改与update得到的代码不冲突,则自动合并。如果冲突(比如对同一行代码进行了修改),则出现”One or more files are in a conflicted state.“红色警告,并产生几个文件记录冲突。一般情况下,我们不要直接编辑冲突文件。而按照以下操作手工解决冲突。 在资源管理器中,选择commit时冲突的那个文件,鼠标右键菜单选择”Edit conficts”。 出现界面,分为”Theirs”、”Mine”和”Merged”3部分,表示”别人修改的内容”、”我修改的内容”和”合并后的结果”3部分。我们是要将”别人修改的内容”和”我修改的内容”有取舍地合并起来,形成”合并后的结果”。 合并一般分为4种情况: 保留”我的修改”,舍弃”别人的修改”。鼠标右键点击Mine框的相应行,点击”Use this text block”。 舍弃”我的修改”,保留”别人的修改”。鼠标右键点击Theirs框的相应行,点击”Use this text block”。 同时保留”我的修改”和”别人的修改”,并将”我的修改”放在前面。鼠标右键点击Mine 框的相应行,点击”Use text block from mine before theirs”。 同时保留”我的修改”和”别人的修改”,并将”别人的修改”放在前面。鼠标右键点击Mine框的相应行,点击”Use text block from theirs before mine”。 合并完成,Ctrl+S存盘,退出。 然后,在资源管理器中,选择冲突文件,鼠标右键菜单选择”Resolved”,标记冲突已解决。系统会自动删除因冲突而新建的文件。此时,就可以继续进行commit操作了。 本文来自CSDN博客,转载请标明出处:https://www.360docs.net/doc/7116713744.html,/gori/archive/2009/04/12/4067588.aspx

SVN解决版本冲突问题

SVN解决版本冲突功能 1代码的分支管理策略 关于代码管理的分支和发布策略,目前主要有两种:一种是主干作为新功能开发主线,分支用作发布。另一种是分支用作新功能开发,主干作为稳定版的发布。 1.1分支用来发布 典型操作步骤如下: 1) 开发者提交所有的新特性到主干。每日的修改提交到/trunk:新特性,bug修正和其他。 2) 这个主干被拷贝到“待发布”分支。当小组认为软件已经做好发布的准备(如,版本1.0) 然后/trunk会被拷贝到/branches/1.0。 3) 项目组继续并行工作,一个小组开始对分支进行严酷的测试,同时另一个小组在/trunk继续 新的工作(如,准备2.0),如果一个bug在任何一个位置被发现,错误修正需要来回运送。 然而这个过程有时候也会结束,例如分支已经为发布前的最终测试“停滞”了。 4) 分支已经作了标记并且发布,当测试结束,/branches/1.0作为引用快照已经拷贝到/tags/1.0.0, 这个标记被打包发布给客户。 5) 分支多次维护。当继续在/trunk上为版本2.0工作,bug修正继续从/trunk运送到/branches/1.0, 如果积累了足够的bug修正,管理部门决定发布1.0.1版本:拷贝/branches/1.0到/tags/1.0.1, 标记被打包发布。 整个过程随着软件的成熟不断重复:当2.0完成,一个新的2.0分支被创建,测试、打标记和最终发布,经过许多年,版本库结束了许多版本发布,进入了“维护”模式,许多标记代表了最终的发布版本。 这种分支管理策略被广泛的应用于开源项目。比如freebsd的发布就是一个典型的例子。 freebsd的主干永远是current,也就是包括所有最新特性的不稳定版本。然后随着新特性的逐步稳定,达到一个发布的里程碑以后,从主干分出来一个stable分支。freebsd是每个大版本一个分支。也就是说4.x,5.x,6,x各一个分支。每个发布分支上只有bug修改和现有功能的完善,而不会再增加新特性。新特性会继续在主干上开发。当稳定分支上发生的修改积累到一定程度以后,就会有一次发布。发布的时候会在稳定分支上再分出来一个 release分支。以 6.x为例,就会有 6.0,6.1,6.2…等发布分支。 这种发布方法非常适用于产品线的发布管理。产品是要卖的,以前卖给客户的版本仍需要继续维护,而为了以后的市场,新功能也不断地在增加。这种管理方法对已发布产品的维护工作和下一代产品的开发工作进行了隔离。对于已经发布的产品,只有维护的补丁发布。而新发行的产品不仅包括了所有的bug修改,还包括了新功能。 这种方法具有如下缺点:首先,必须对主干上的新功能增加进行控制。只能增加下一个发布里面计划集成进去的新特性。而且,已经在主干上集成的新特性中的任何一个,如果达不到里程碑的要求,稳定分支就不能创建,这很有可能影响下一个发布的计划。开源项目可能这方面的压力小一些,但是商业产品开发如果碰到这种情况就危险了。还有一个缺点就是bug修改必须在各个分支之间合并。 从分支和合并的一些实践经验上看,各个长期存在的分支之间必须要周期性的进行合并,否则很容易引发合并冲突。可是各个stable分支以及release分支之间恰好是不能进行合并而且还要长期存在的。因此,采用这种分支策略可能碰到的最大问题就是某个分支上的bug修改内容往其它分支merge 的时候出现的冲突。而且一旦发现一个bug,调查这个bug影响哪些分支的工作会随着维护的发布分支的数量而增加。

SVN冲突解决方法大全

SVN冲突解决方法大全 2010-05-27 09:33 佚名我要评论(0)字号:T | T 本文和大家一起来学习SVN冲突解决和winmerge使用手册,本文介绍了几个SVN冲突解决的方法,希望大家通过本文的学习能够掌握,欢迎大家一起来学习。 AD: 本节向大家介绍一下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 以为冲突解决,而使代码库不正确。 解决冲突详细文 档:https://www.360docs.net/doc/7116713744.html,/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve 解决冲突(合并别人的修改) 我们可以使用svnstatus-u来预测冲突,当你运行svnupdate一些有趣的事情发生了: $svnupdate UINSTALL GREADME Cbar.c Updatedtorevision46. U和G没必要关心,文件干净的接受了版本库的变化,文件标示为U表明本地没有修改,文件已经根据版

SVN版本冲突解决详解

版本冲突原因: 假设A、B两个用户都在版本号为100的时候,更新了kingtuns.txt这个文件,A用户在修改完成之后提交kingtuns.txt到服务器,这个时候提交成功,这个时候kingtuns.txt文件的版本号已经变成101了。同时B用户在版本号为100的kingtuns.txt文件上作修改,修改完成之后提交到服务器时,由于不是在当前最新的101版本上作的修改,所以导致提交失败。 版本冲突现象: 冲突发生时,subversion会在当前工作目录中保存所有的目标文件版本[上次更新版本、当前获取的版本(即别人提交的版本)、自己更新的版本、目标文件]。 假设文件名是kingtuns.txt 对应的文件名分别是: kingtuns.txt.r101 kingtuns.txt.r102 kingtuns.txt.mine kingtuns.txt。同时在目标文件中标记来自不同用户的更改。 版本冲突解决: 场景: 1、现在A、B两个用户都更新kingtuns.txt文件到本地。

2、文档中原始文件内容如下: 3、A用户修改文件,添加内容“A用户修改内容”完成后提交到服务器

4、B用户修改文件,添加内容“B用户修改内容”完成后提交到服务器

B用户提交更新至服务器时提示如下: B用户将文件提交至服务器时,提示版本过期:首先应该从版本库更新版本,然后去解决冲突,冲突解决后要执行svn resolved(解决),然后在签入到版本库。在冲突解决之后,需要使用svn resolved(解决)来告诉subversion冲突解决,这样才能提交更新。 解决冲突有三种选择: A、放弃自己的更新,使用svn revert(回滚),然后提交。在这种方式下不需要使用svn resolved (解决) B、放弃自己的更新,使用别人的更新。使用最新获取的版本覆盖目标文件,执行resolved filename并提交(选择文件—右键—解决)。 C、手动解决:冲突发生时,通过和其他用户沟通之后,手动更新目标文件。然后执行resolved

svn冲突的产生与解决

svn 冲突的产生与解决 1、如何产生冲突 当开发人员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版本也提交则会产生冲突,无法提交,需要先svn update,此时会在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、解决冲突 第一种,利用update的选项进行冲突解决,也就是说不管当前拷贝副本是否是最新版本,都使用—accept参数作为冲突处理方式 –accept ARG : specify automatic conflict resolution action (?postpone‘, ?base‘, ?mine-conflict‘, ?theirs-confl ict‘, ?mine-full‘, ?theirs-full‘, ?edit‘, ?launch‘) (p) postpone – mark the conflict to be resolved later //让文件在更新完成之后保持冲突状态。 (df) diff-full – show all changes made to merged file //使用标准区别格式显示base修订版本和冲突文件本身的区别。 (e) edit – change merged file in an editor //用你喜欢的编辑器打开冲突的文件,编辑器是环境变量EDITOR设置的。 (r) resolved – accept merged version of file //完成文件编辑之后,通知svn 你已经解决了文件的冲突,它必须接受当前的内容—从本质上讲就是你已经―解决了‖冲突。 (mf) mine-full – accept my version of entire file (ignore their change//丢弃新从服务器接收的变更,并只使用你查看文件的本地修改。 (tf) theirs-full – accept their version of entire file (lose my changes)//丢弃你对查看文件的本地修改,只使用从服务器新接收的变更。 (l) launch – launch external tool to resolve conflict//启动一个外置程序来执行冲突解决,这需要一些预先的准备。 (h) help – show this list //显示所有在冲突解决时可能使用的命令。

svn常见问题

Svn常见问题及相关原因 1. svn: Server sent unexpected return value (500 Internal Server Error) in response to OPTIONS request for 'https://www.360docs.net/doc/7116713744.html,/svn/test' 错误的用户名 检查登录的用户名是否输入错误 svn: 服务器发送了意外的返回值(500 Internal Server Error),在响应“OPTIONS” 的请求“https://www.360docs.net/doc/7116713744.html,/svn/test” 中 2. svn: OPTIONS of 'https://www.360docs.net/doc/7116713744.html,/svn/test': authorization failed: Could not authenticate to server: rejected Basic challenge (https://www.360docs.net/doc/7116713744.html,) 错误的口令 用正确的用户名/口令登录 svn: 方法OPTIONS 失败于“https://www.360docs.net/doc/7116713744.html,/svn/test”: 认证失败: Could not authenticate to server: rejected Basic challenge (https://www.360docs.net/doc/7116713744.html,) 3. svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request for 'https://www.360docs.net/doc/7116713744.html,/svn/test' 用户无权限 联系管理员,为用户分配权限 svn: 服务器发送了意外的返回值(403 Forbidden),在响应“OPTIONS” 的请求“https://www.360docs.net/doc/7116713744.html,/svn/test” 中 4. svn: OPTIONS of 'https://www.360docs.net/doc/7116713744.html,/svn/test': 200 OK (https://www.360docs.net/doc/7116713744.html,) 服务器地址错误,是普通Web页面,不支持SVN的WebDAV 协议 确认输入正确的SVN 服务地址。可以在浏览器中输入该地址进行确认 svn: 方法OPTIONS 失败于“https://www.360docs.net/doc/7116713744.html,/svn/test”: 200 OK (https://www.360docs.net/doc/7116713744.html,) 5. The version of your subversion (client) is below 1.5.0, upgrade to 1.5.0 or above. SVN below 1.5.0 can not handle mergeinfo properly. It can mess up our automated merge tracking! 是由于客户端的软件版本低于1.5.0造成的。服务器端对客户端软件版本进行了限制,以免对合并跟踪破坏。 升级本地的Subversion客户端软件到1.5.0或以上版本。

svn 常见报错

常见错误提示: 1:?.? is not a working copy. Can?t open file ….svn/entries?:系统找不到指定的路径。 原因是输入的访问路径不正确,如svn://192.168.6.200/如果最后少写了“/”,就会出现这种错误提示。 2:将文件checkout之后,没有出现SVN的图标,是怎么回事? 有些时候在客户端Checkout文件后,SVN的系统图标也会不显示,可以执行一下“Clean up”,就会出现SVN的系统图标。 3:为什么添加的文件,别人看不到,版本库里也没有? 最可能的原因是,你只是执行了“Add”而没有“Commit”,这样只是在本地注明某个文件是预定要增加的,而没有实际添加到版本库中,要添加到版本库必须执行“Commit”。删除文件也是一样。 4 :“Commit failed。……You have to update your working copy first”提交失败,需要首先执行更新操作。多人同时修改同一文件,在提交前其他人已经抢先提交到SVN服务器中,导致该错误;解决方法:对工作复本中的文件进行更新即可。 5. 更新时提示文件发生冲突:“One or more files are not a conflicted state。” 多人同时修改同一文件的同一部分,SVN无法自动进行合并,会导致该错误;解决方法:对工作复本中的文件和服务器的文件进行比较,手工合并即可。 6.“Commit failed;File already exists”提交失败,文件**已存在。 版本管理系统在改变你的计算机上的工作副本时,是非常的小心的。在做任何事情之前,它都尽可能把您的意图写到你的计算机上的日志文件中去。但如果偶然地操作中断了(例如:突然停电了,您的计算机死机了),那么日志文件记录就可能同您最后的工作状态不一致。一种建议解决途径:先把要提交的东西拷出来放到其它目录,再更新本地文件,然后把拷出来的文件重新放回去提交。 7:执行clean up时,出现错误“Subversion reported an error while doing a cleanup!” '**' is not a working copy directory ” 遇到这种情况,先删除隐藏文件夹.svn中的tmp下面的临时文件,再执行clean up。 8:因为仓库与目录很多,使用TSVN每次选择目录URL of repository有很多地址,如何才清除呢?像清除浏览器中的历史那样,用什么方法呢? 右键->TortoiseSVN->Settings->Saved Data,就可以清除你想要的东西了,包括URL、log、窗口大小、密码缓存等。 9:在SVN中选中一个目录show log时,出现了某些版本只显示版本号和(no date),没有其他信息,什么原因引起的? 出现了(no date)的revision,为其他人修改了你所没有权限访问的某个目录下的文件。

SVN管理规范方案

Subversion管理规范 一Subversion介绍 Subversion (Subversion)是一个时间机器,随时记录文件和目录的每次改动,例如:文件的增加、删除、重新排列文件等。同时SUBVERSION允许你恢复以前旧版本的数据,或者检查数据变化的历史。 SVN使用类似数据库事物的方式来处理用户提交入库的过程,整个改动要么成功的被提交,要么被中断并回滚。在数据提交完之前,其他人是看不到用户提交的修改文件,你看到的要么是改动之前的状态,要么是改动之后的状态。这样的行为被称为“原子提交”。原子提交很有用,因为它能保证所有相关人员看到的总是相同的东西。原子提交过程的其中一步就是包括把你的所有改动打包为

一个“修订集”(有时被称为改动集),并且再给个改动标记的修订号(绿色勾变为红色叹号)。 图 1 图1总体概括了SVN 整个操作过程:首先用户从版本库通过网络“检出”到本地工作副本中,然后,在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中,如果本地工作副本中版本较系统版本过时,用户使用“更新”功能与系统上版本保持一致。 二 Subversion 的目录结构 每个SVN 版本库下需要有trunk(可用项目名做目录名)、branches 及tags 目录,trunk 表示开发时版本存放的目录,即在开发阶段的代码都提交到该目录上。branches 表示发布的版本存放的目录,即项目上线时发布的稳定版本存放在该目录中。tags 表示保存测试无问题的发布版本,不可修改。branches/tags 命名规则:项目名[_说明]_版本号。 在这需要说明下分三个目录的原因,如果项目分为一期、二期、三期等,那么一期上线时的稳定版本就应该在一期完成时将代码copy 到branches 上,这样二期开发的代码就对一期的代码没有影响,如新增的模块就不会部署到生产环境上。而branches 上的稳定的版本就是发布到生产环境上的代码,如果用户使用的过程中发现有bug ,则只要在branches 上修改该bug ,修改完bug 后再编译branches 上最新的代码发布到生产环境即可。tags 的作用是将在branches 上修改的bug 的代码合并到trank 上时创建个版本标识,以后branches 上修改的bug 代码再合并到trunk 上时就从tags 的version 到branches ,最新的version 合并到trunk ,以保证前期修改的bug 代码不会在合并。 版本库 本地工作副本

svn基本操作试题及答案

《SVN基本操作》试题 (说明:本卷满分100分,考试时间30分钟,考试方式闭卷) 所在部门:______________姓名:___________得分:________ 一、填空题(每空格5分,共20分) 当发生提交冲突的时候,可使用SVN的DIFF来进行两个版本文件的比较,为保证解决冲突,合并版本的时候,不会删除前版本的内容,建议使用手工解决冲突,而不是使用svn的Merge自动进行版本合并!发生冲突的时候,应知会前版本提交人,一起解决冲突,合并版本! 二、选择题(每题2分,共30分) 1.在空白处,单击右键,选择“TortoiseSVN”(A)便可以进入SVN版本库浏览器。 A、Repo-browser B、Createrepositoryhere C、Settings D、Import 2.在URL中输入访问路径后,会弹出Authentication对话框,在对话框中输入用户名和密码,点击(B)可保存用户名和密码。 A、Authenticationdata B、SaveAuthentication C、Settings D、SavedData 3.如果想要清除服务器上的所有认证缓存,可以通过TortoiseSVN Settings(设置)对话框中的SavedData(A),按clear或者clearall按钮即可清空。 A、Authenticationdata B、SaveAuthentication C、URLhistory D、Logmessages 4.绿色的对勾标记代表(A),红色的感叹号标记代表(D),蓝色的加号代表(B)。 A、工作副本状态正常 B、文件已被计划加入版本控制 C、提交过程中出现冲突 D、工作副本已修改 5.把本地的文件夹下的文件添加到服务器上的某个目录下面,那么在本地的目录右键TortoiseSVN(A)进行。 A、Import B、Createrepositoryhere C、Settings D、Export 6.在SVN版本库浏览器内,选好目录,于空白处右键选择(B)添加文件、选择(C)添加文件夹。 A、createfolder B、Addfile C、Addfolder D、Export 7.在本地计算机硬盘新建的空白文件夹内,右键选择(A)可以从SVN服务器下载受版本控制的文件。

【黑马程序员】svn conflict 冲突解决

【黑马程序员】svn conflict 冲突解决 1. 同一处修改文件冲突 开发人员都知道代码管理工具是开发中一个必不可少的工具,这里也不废话详细介绍了。不管你个人喜欢git还是svn还是其他,但还有一大部分公司在使用svn做代码管理工具。这里详细介绍下SVN提交文件时冲突问题的解决方式。 假设A、B两个用户,他们分别从svn服务器中检出了test1.txt文件,此时A、B、服务器三个地方的test1.txt的版本都是13(我测试环境的当前svn 赋予的版本号)。A、B文件的内容如下图(左A右B):· 接下来,B用户添加一句话并提交,内容如下:

此时B用户和服务器的test1.txt的版本都变为14,只有A用户的test1.txt的版本还为13。接下来A用户添加一句“aa”,然后提交 由于A用户是在13版本上做的修改,而服务器已经是14版本了,所以会提交失败:

接下来就是我们要解决的问题了,解决方法分为以下两种方式。第一种方式:提交失败后直接选择revert,省去了解决冲突问题;第二种方式:提交失败后选择更新文件,这时会有冲突问题。详细介绍如下:1.1. 解决方式一 A放弃自己修改的内容,进行Revert操作,使其test1.txt成为13版本的最初内容。然后update 使其test1.txt成为14版本,再在14版本上修改提交。操作如下图:

==》 ==>然后再修改提交 1.2. 解决方式二 因为版本过时,提交失败后。A用户直接选择更新操作,结果如下图所见

(这里声明下,不要被文件显示的图标所迷惑,这是其他软件对它做了关联导致的,没啥影响)这里详细说一下产生冲突后的这几个文件,: test1.txt.mine---这个文件是A用户在13版本中做了修改要提交的文件。它的内容是:13版本内容+A用户的修改 test1.txt.r13----这个文件是A用户最初的13版本的test1.txt。它的内容是:13版本内容test1.txt.r14----这个文件时svn服务器中test1.txt的最新版本,这里既是B用户提交后的14版本。它的内容是:13版本内容+B用户的修改test1.txt--------由于A用户选择了直接更新,此文件就是svn将最新版本14 与A用户的修改合并后的文件。它的内容如下:

SVN冲突解决

解决版本冲突的命令。在冲突解决之后,需要使用svn resolved来告诉subversion冲突解决,这样才能提交更新。冲突发生时,subversion会在Work Copy中保存所有的目标文件版本(上次更新版本、当前获取的版本,即别人提交的版本、自己更新的版本、目标文件。假设文件名是sandwich.txt,对应的文件名分别是:sandwich.txt.r1、sandwich.txt.r2、sandwich.txt.mine、sandwich.txt)。同时在目标文件中标记来自不同用户的更改。 解决冲突的办法: - 手动解决:冲突发生时,通过和其他用户沟通之后,手动更新目标文件。然后执行svn resolved filename来解除冲突,最后提交。 - 放弃自己的更新,使用别人的更新。使用最新获取的版本覆盖目标文件,执行svn resolved filename并提交。 - 放弃自己的更新,使用svn revert,然后提交。在这种方式下不需要使用svn resolved。 对于svn resolved命令需要非常小心,必须是非常确定冲突已经解决才能使用。否则,会导致Subversion以为冲突解决,而使代码库不正确。 解决冲突详细文档: https://www.360docs.net/doc/7116713744.html,/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve 解决冲突(合并别人的修改) 我们可以使用svn status -u来预测冲突,当你运行svn update一些有趣的事情发生了: $ svn update U INSTALL G README C bar.c Updated to revision 46. U和G没必要关心,文件干净的接受了版本库的变化,文件标示为U表明本地没有修改,文件已经根据版本库更新。G标示合并,标示本地已经修改过,与版本库没有重迭的地方,已经合并。 但是C表示冲突,说明服务器上的改动同你的改动冲突了,你需要自己手工去解决。当冲突发生了,有三件事可以帮助你注意到这种情况和解决问题: ●Subversion打印C标记,并且标记这个文件已冲突。 ●如果Subversion认为这个文件是可合并的,它会置入冲突标记—特殊的横线分开 冲突的“两面”—在文件里可视化的描述重叠的部分(Subversion使用svn:mime- type属性来决定一个文件是否可以使用上下文的,以行为基础合并,更多信息可以看“svn:mime-type”一节)。 ●对于每一个冲突的文件,Subversion放置三个额外的未版本化文件到你的工作拷 贝: ●filename.mine ●你更新前的文件,没有冲突标志,只是你最新更改的内容。(如果Subversion认 为这个文件不可以合并,.mine文件不会创建,因为它和工作文件相同。) ●filename.rOLDREV

SVN管理规范

1、目的: 本制度为研发部SVN配置管理的准则和依据,所有与SVN配置管理的行为都必须遵照并服从于本制度。 2、适用范围: 本制度适用于研发部全体员工。 3、控制要求和方法: 3.1 操作流程 首先用户从svn版本库通过网络“检出”到本地工作副本中,然后,在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中,如果本地工作副本中版本较系统版本过时,用户使用“更新”功能与系统上版本保持一致。 3.2 帐号注册、权限申请 1. 用户帐号注册:新进员工没有SVN帐号,通过联系SVN管理员,注明申请SVN普 通帐号,管理员处理完帐号注册事宜后,通知使用并介绍使用规范。 注:普通帐号,只对目录有读取权限,无法更改。 2. 权限的申请:根据员工所参与的项目,SVN管理员对其开放相应目录的读、写权限。 3. 账号注销:员工离职后,对其账号进行注销。 3.3 操作规范 1. 每日进行开发工作之前更新代码,下班时提交代码。 2. 各员工需牢记各自的账户和密码,不得向他人透漏,严禁使用他人账户进行SVN各项操作。

3. 不要签出整个目录,除非特别必要,不应同时签出过多的项目。 4. 文件提交时要求必须提交注释,注明相关修改信息,日志信息描述的越详细越好,让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。 5. 代码变动及时提交,避免丢失本地修改后无法恢复。 6. 在提交之前要编译代码并修正错误。要保证新增加的文件同时被提交,否则只在你本地能正常工作,导致其它人不能编译通过。 7. 提交之前要测试所改变的应用,测试改变后的效果是否达到预期的目的。 8. 多次检查提交的内容。提交之前应先做SVN更新或与资源库同步,注意到SVN关于冲突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别,确认它们是不是你真正想要提交的。 9. 如果别人和自己更改的是同一个文件,那么Update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。 10. 在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。这样既能了解别人修改了哪些文件,同时也能避免SVN合并错误导致代码有错。 11. 提前宣布修改计划。当你计划进行修改,需要影响到SVN里的许多文件时,先通过邮件或者当面通知其他开发者。例如,修改底层数据库模块时,有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备,也会对修改提出意见和建议。 12. 每次提交尽量是一个最小粒度的修改。比如一个小功能提交一次。 13. 不要提交不能通过编译的代码。代码在提交之前,首先要确认自己能够在本地编译。如果在代码中使用了第三方类库,要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。 14. 提交时注意不要提交本地自动生成的文件,提交的文件必须是开发者共用的程序文件,程序编译中产生的中间文件或文件夹,如/Debug/、/Release/、*.ncb、*.obj、*.o、Thumbs.db、/build/、*.class、/classes/、/data/等不要提交到SVN里。 15. SVN管理员需对SVN的所有项目定期备份。 16. SVN的资料不允许公开给其他部门人员,确实要分发的,必须通过总经理同意。 重要说明文件要求: 硬件开发:

SVN解决冲突如果你想彻底删除不使用垃圾箱在点击删除时请按着Shift键

SVN解决冲突(如果你想彻底删除(不使用垃圾箱),在点击删除时,请按着Shift键) 解决冲突 偶尔,当你从版本库更新、合并文件时,或者切换工作副本至一个不同的URL 时你会遇到冲突。有两种冲突: 文件冲突 当两名(或更多)开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。 树冲突 当一名开发人员移动、重命名、删除一个文件或文件夹,而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。 文件冲突 当两名或更多开发人员修改了同一个文件中相邻或相同的行时就会发生文件冲突。由于 Subversion 不知道你的项目的具体情况,它把解决冲突的工作留给了开发人员。一旦出现冲突,你就应该打开有问题的文件,查找以字符串<<<<<<<开头的行。有冲突的区域用如下的方式标记: <<<<<<< 文件名 你的修改 ======= 合并自版本库中的代码 >>>>>>> 版本 对于每个冲突的文件 Subversion 在你的目录下放置了三个文件: 文件名. 这是你的文件,在你更新你的工作副本之前存在于你的的工作副本中——也就是说,没有冲突标志。这个文件除了你的最新修改外没有别的东西。 文件名.旧版本 这是在你更新你的工作副本之前的基础版本(BASE revision)文件。也就是说,它是在你做最后修改之前所检出的文件。 文件名.新版本 这个文件是当你更新你的工作副本时,你的 Subversion 客户端从服务器接收到的。这个文件对应于版本库中的最新版本。

你可以通过TortoiseSVN → 编辑冲突运行外部合并工具/冲突编辑器,或者你可以使用任何别的编辑器手动解决冲突。你需要冲定哪些代码是需要的,做一些必要的修改然后保存。 然后,执行命令TortoiseSVN → 已解决并提交人的修改到版本库。需要注意的是已解决命令并不是真正的解决了冲突,它只是删除了和两个文件,允许你提交修改。 如果你的二进制文件有冲突,Subversion不会试图合并文件。本地文件保持不变(完全是你最后修改时的样子),但你会看到文件。如果你要撤消你的修改,保留版本库中的版本,请使用还原(Revert)命令。如果你要保持你的版本覆盖版本库中的版本,使用已解决命令,然后提交你的版本。 你可以右击父文件夹,选择TortoiseSVN → 已解决...,使用“已解决”命令来解决多个文件。这个操作会出现一个对话框,列出文件夹下所有有冲突的文件,你可匝≡窠男┍昙浅梢呀饩觥 树冲突 当一名开发人员移动、重命名、删除一个文件或文件夹,而另一名开发人员也对它们进行了移动、重命名、删除或者仅仅是修改时就会发生树冲突。有很多 种不同的情形可以导致树冲突,而且不同的情形需要不同的步骤来解决冲突。 当一个文件通过 Subversion 在本机删除后,文件也从本机文件系统中删除。因此即使它是树冲突的一部分,却既不能显示冲突的叠加图标也不能通过右键单击来解决冲突。使用检查修改对话框来获得编辑冲突选项。 TortoiseSVN 能够协助找到合并更改的正确位置,但是需要作一些额外的工作来整理冲突。请牢记: 当进行一次更新操作后,工作副本的基础文件将会包括每一个项目在执行更新操作时版本库中的版本。如果你在进行更新后再撤销更改,工作副本将返回到版本库的状态,而不是你开始进行更改前的状态。 . 本地删除,当更新时有更改进入 开发人员 A 修改并将其提交至版本库中 开发人员 B 同时在他的工作副本中将文件改名为,或者仅仅是删除了或它的父文件夹。 更新开发人员 B 的工作副本会导致树冲突: 在工作副本中,被删除了,但是被标记为树冲突。

TortoiseSVN版本冲突处理

TortoiseSVN版本冲突处理 当文件被别人修改并提交到SVN服务器后,如果自己本地的文件还没有更新为最新的版本,而且已经作了修改,这时候提交将不会成功,系统会提示你的版本已经过期,并要求你先进行更新,再提交,如下图所示: 依照提示进行更新,如果从服务器更新下来的最新版本和本地的版本相较于服务器上一版本都在文件的同一块地方做了修改,则会提示版本冲突,提示页面如下图所示:

同时,在文件夹目录窗口下,可以发现该文件被标注了黄色感叹号,且多出了三个标注有问号的临时版本文件,如下图所示: 此时,需要进行版本冲突处理: 鼠标右键点击冲突文件,选择TortoiseSVN—Edit conflicts进行处理:

版本冲突处理界面如下图所示: 画面上方左侧为从服务器更新下来的版本(Theirs),上方右侧为本地版本(Mine),下方为处理合并之后的预览版本。 点击工具栏上红色向下的箭头 系统会自动跳转到下一部分冲突的区块,并选中冲突的区块。此时点击工具栏上蓝色向左或者向右箭头可以选择使用更新版本还是本地版本 按钮具体功能,鼠标移上之后会有提示,Theirs表示更新下来的版本,Mine表示本地版本。选择版本之后,可以在画面下方查看预览版本。预览版本的冲突区块在选择版本之前是以?问号显示,版本选择后则以选择版本对应的区块替代显示,如下图所示(此例版本选择Mine版本):

依次完成所有冲突的区块,选择保存文件: 再点击工具栏上如下图所示按钮: 将该文件标记为版本冲突已经解决的文件。 此时,再在文件夹目录下观察该文件,就没有冲突的标记了,而只有自己所做修改 的标记,如下图所示: 此时,该文件就可以被上传了。

开源版本控制SVN 树冲突、目录丢失问题及解决机制探讨

SVN 树冲突和目录丢失问题(1) 临下班了,一个老朋友(之后用yzw代称)在MSN 上呼我。说他的SVN 遇到问题了: ?在执行分支合并时,一个目录发生了树冲突 ?直接在硬盘上将该目录删除 ?之后执行svn update 该目录不能检出 ?不知道树冲突为何物,也不知道目录怎么变成了一团糟 好吧,谁让他公司的SVN 是我给部署的呢?让他(yzw)执行svn status 命令,看看显示什么信息,然后我在本地建立一个模型,争取重现并解决他的问题。 在已经一团糟的目录下,执行svn 显示的信息如下: 看来他遇到的树冲突,是因为在两个分支同时创建了一个同名目录somedir,然后在合并更新时出现树冲突。 重现问题的过程 版本库准备 1.创建svn 版本库于/tmp/svnserver 2.检出版本库到目录~/tmp/svntf 下(windows用户需要知道的是:~ 代表我的主目录 /home/jiangxin 是也) 3.创建SVN 三个顶级目录:trunk tags branches 4.创建分支branches/0.x 5.在branches/0.x 分支下创建目录somedir,并增加一个文件somedir/branch.txt 6.在主线trunk 下也创建一个目录somedir,并增加一个文件somedir/trunk.txt 看看目前的版本情况

备份当前的 .svn 目录 直接拷贝 .svn 到 .svn-orignal,以便在出现意外的时候,进行参照。 “.svn*”。(问题优点复杂化了,算了) 合并分支改动,引发异常

o而我的结果是: o看来,还需要作些工作才能完全重现错误。 15.这时我又备份了一下 .svn 目录,将 .svn 复制到 .svn-merge-conflict,以便后面比较 实际上,通过比较 .svn 目录和之前备份的 .svn-merge-conflict 可以看出端倪: 执行svn status,看到本地工作目录的冲突状态已经消失了,一切看起来正常了。 但是,慢着,此时somedir 目录没有了! 实际上,这时版本库中还有somedir 目录,我们可以用svn ls 命令查看:

相关文档
最新文档