视频网站公共关系怎么做,网站做搜索要用数据库吗,wordpress 响应式 企业网站,沈阳网站建设模板本文无条理性#xff0c;仅作自我参考。 花费了两个半下午#xff0c;走马观花的看了一下说明文档#xff0c;SVN设计的太复杂#xff0c;对我这样的#xff0c;不在一个集体的的业余开发者#xff0c;要理解起来真是太难了。。。。 分支 Make branches as often as yo…本文无条理性仅作自我参考。 花费了两个半下午走马观花的看了一下说明文档SVN设计的太复杂对我这样的不在一个集体的的业余开发者要理解起来真是太难了。。。。 分支 Make branches as often as you want.这是SVN官方说明中的一句话 Theres nothing special about this working copy; it simply mirrors a different directory in the repository. 版本控制系统的一个特性是能够把各种修改分离出来放在开发品的一个分割线上。这条线被称为分支。分支经常被用来试验新的特性而不会对开发有编译错误的干扰。当新的特性足够稳定之后开发品的分支就可以混合回主分支里(主干线). 假设已经建立分支如果其他人的 working copy 在trunk上当你提交分支的更改时主干不会发生改变。 分支背后的关键概念You should remember two important lessons. First, Subversion has no internal concept of a branch—it knows only how to make copies.When you copy a directory, the resultant directory is only a “branch” because you attach that meaning to it. You may think of the directory differently,or treat it differently, but to Subversion its just an ordinary directory that happens to carry some extra historical information. 在版本库中的复制都是“廉价复制”。 Second, because of this copy mechanism, Subversions branches exist as normal filesystem directories in the repository. This is different from other version control systems, where branches are typically defined by adding extra-dimensional “labels” to collections of files. The location of your branch directory doesnt matter to Subversion. Most teams follow a convention of putting all branches into a /branches directory, but youre free to invent any policy you wish. 合并(保持分支同步) ------frequently keeping your branch in sync with the main development line helps prevent “surprise” conflicts when it comes time for you to fold your changes back into the trunk. 由于有众多的人参与项目大多数人拥有主干拷贝是很正常的任何人如果进行一个长周期的修改会使得主干陷入混乱所以通常的做法是建立一个私有分支提交修改到自己的分支直到这阶段工作结束。所以好消息就是你和Sally不会互相打扰坏消息是有时候分离会太远。 记住“闭门造车”策略的问题当你完成你的分支后可能因为太多冲突已经无法轻易合并你的分支和主干的修改。 相反在你工作的时候你和Sally仍然可以继续分享修改这依赖于你决定什么值得分享Subversion给你在分支间选择性“拷贝”修改的能力当你完成了分支上的所有工作所有的分支修改可以被拷贝回到主干。在Subversion术语里这种从一个分支复制修改到另一个分支的活动称为合并它是使用svn merge命令执行。 svn merge另一个常用的做法 是取消已经做得提交假设你愉快的在/calc/trunk工作你发现303版本对integer.c的修改完全错了它不应该被提交你可以使用svn merge来“取消”这个工作拷贝上所作的操作然后提交本地修改到版本库你要做得只是指定一个相反的区别。(你可以通过指定--revision 303:302--change -303 svn merge与svn diff ......At this point, the wise thing to do is look at the changes carefully with svn diff, and then build and test your branch. Notice that the current working directory (“.”) has also been modified; the svn diff will show that its svn:mergeinfo property has been either created or modified. This is important mergerelated metadata(元数据) that you should not touch, since it will be needed by future svn merge commands. 但是svn merge没有这样的保证会导致很多的混乱用户可以询问服务器比较任何两个树即使一个与工作拷贝毫不相关的这意味着有潜在的人为错误用户有时候会比较两个错误的树创建的增量数据不会干净的应用svn merge会尽力应用更多的增量数据但是有一些部分也许会难以完成就像Unix下patch命令有时候会报告“failed hunks”错误svn merge会报告“skipped targets” 指出svn diff和svn merge区别的重要性在于前一个命令忽略祖先如果你询问svn diff来比较文件foo.c的版本99和102你会看到行为基础的区别diff命令只是盲目的比较两条路径但是如果你使用svn merge是比较同样的两个对象它会注意到他们是不关联的而且首先尝试删除旧文件然后添加新文件输出会是一个删除紧接着一个增加。 如果你使用svn merge进行比较你会看到第一个目录树被删除而第二个树添加上在这个情况下你仅仅是希望svn merge以路径为基础比较两棵树而忽略文件和目录的不相关性当为合并命令添加--ignoreancestry选项时就会像svn diff一样工作。 切换 “Switching” a working copy that has no local modifications to a different branch results in the working copy looking just as it would if youd done a fresh checkout of the directory. Its usually more efficient to use this command, because often branches differ by only a small degree. The server sends only the minimal set of changes necessary to make your working copy reflect the branch directory. svn switch命令改变存在的工作拷贝到另一个分支然而这个命令在分支上工作时不是严格必要的它只是提供了一个快捷方式。在前面的例子里完成了私有分支的建立你取出了新目录的工作拷贝相反你也可以简单的告诉Subversion改变你的/calc/trunk的工作拷贝到分支的路径。 svn switch命令也可以带--revision(-r)参数所以你不需要一直移动你的工作拷贝到分支的HEAD。当然许多项目比我们的calc要复杂的多有更多的子目录Subversion用户通常用如下的法则使用分支1. 拷贝整个项目的“trunk”目录到一个新的分支目录。2. 只是转换工作拷贝的部分目录到分支。 切换和更新 Have you noticed that the output of svn switch and svn update looks the same? The switch command is actually a superset of the update command. svn switch是svn update的一个变种具有相同的行为当新的数据到达时任何工作拷贝的已经完成的本地修改会被保存。 当你运行svn update时你会告诉版本库比较两个目录树版本库这样做并且返回给客户区别的描述svn switch和svn update两个命令唯一区别就是update会一直比较同一路径。That is, if your working copy is a mirror of /calc/trunk, svn update will automatically compare your working copy of /calc/trunk to /calc/trunk in the HEAD revision. If youre switching your working copy to a branch, svn switch will compare your working copy of /calc/trunk to some other branch directory in the HEAD revision.换句话说一个更新通过时间移动你的工作拷贝一个转换通过时间和空间移动工作拷贝。 If the working copy needs to reflect映射 a new directory within the repository, use just svns witch.If the working copy still reflects the same repository directory, but the location of the repository itself has changed, use svn switch with the --relocate option。 另一个Subversion模型的可爱特性是分支和标签可以有有限的生命周期就像其它的版本化的项目举个例子假定你最终完成了calc项目你的个人分支上的所有工作在合并了你的所有修改到/calc/trunk后没有必要继续保留你的私有分支目录。 在我们的例子里你的个人分支只有一个相对短的生命周期你会为修复一个Bug或实现一个小的特性来创建它当任务完成分支也该结束了。在软件开发过程中有两个“主要的”分支一直存在很长的时间也是很常见的情况举个例子假定我们是发布一个稳定的calc项目的时候了但我们仍会需要几个月的时间来修复Bug你不希望添加新的特性但你不希望告诉开发者停止开发所以作为替代你为软件创建了一个“稳定”分支...。 SVN可以为一个版本库中的内容(主干)建立一个分支.分支和主干完全独立就相当于把代码再复制便宜复制一份重新添加到版本库中。但SVN提供另一个功能就是把主干做出的修改合并到分支中以及把分支修改的内容合并到主干中。当然我们也可以把主干的版本库的路径切换到分支上然后更新来实现把分支的修改更新到主干以及修改分支路径来同步主干的修改。但过程复杂还容易出错。 1.将一个整项目建一个分支. 选择要复制的源位置有三个选项 版本库中的最新版本 新分支直接从仓库中的最新版本里复制出来。不需要从你的工作副本中传输任何数据这个分支的建立是非常快的。 在版本库中指定具体的版本 在仓库中直接复制建立一个新分支同时你也可以选择一个旧版本。假如在你上周发布了项目时忘记了做标记这将非常有用。如果你记不起来版本号通过点击鼠标右键来显示版本日志同时从这里选取版本号。和上次一样不需要从你的工作副本中传输任何数据这个分支建立起来是非常快的。 工作副本 新的分支是一个完全等同于你的本地工作副本的一个副本。如果你更新了一些文件到你的工作副本的某个旧版本里或者你在本地做出了修改这些改变将准确无误的进入副本中。自然而然地这种综合的标记会包含正在从工作副本传输到版本库的数据如果这些数据还不存在的话。 注意:是否把主干的路径切换到新分支把的工作副本自动切换到最新创建的分支 如果勾选了建立分支后在主干里做出的修改并提交后更新会提交到分支上。主干的版本源内容不会变. 但是如果你打算这么做首先要确认你的工作副本没有被修改。如果有修改的话当你转换后这些修改将会混合进你的工作副本分支里。按下确认提交新副本到版本库中。别忘了提供一条日志信息。需要注意的是这个副本是在版本库内部创建的。 为了避免产生困惑。以及失误。建议在建立的时候不要勾上 切换到分支 的选项。如果勾上了我们还是切换回去: 这时你便可以在 /calc/branches/my-calc-branch 分支上开发新的功能且不会影响到其他成员开发或维护主干的内容。 切换操作起来就象更新因为它没有丢弃你在本地做的修改。在工作副本里当你进行切换的时候任何没有提交过的修改都会被混合。如果你不想看到这样的结果那么你可以有两种选择要么在切换前提交修改要么把工作副本恢复到一个已经提交过的版本(比如最新版本)。 2.合并主干的变更到分支上 经常將 开发主干 ( /calc/trunk ) 的变更透过 svn merge 合并至 分支 ( /calc/branches/my-calc-branch )是一个非常好的习惯这样才不会让你脱离主干(trunk) 过久而导致将分支 ( /calc/branches/my-calc-branch) 合并回 主干 ( /calc/trunk ) 时发生许多冲突。 从主干 ( /calc/trunk ) 合并至分支 ( /calc/branches/my-calc-branch ) 通常选第 1 个也就是 [Merge a range of revisions] 注意.我们是在分支上使用的 Merge 功能.因为是要在分支上应用主干的更新. 在 Merge 的窗口有以下注意事項 1.合并的来源由于我们打算从主干 ( /calc/trunk ) 合并至分支 ( /calc/branches/my-calc-branch )所以合并的來源要选 /calc/trunk 才对2.合并的结果会直接与目前「工作目录」(Working Copy) 做比对并修改目前工作目录中的所有文件。因此建议在做合并之前可以将所有尚未 commit 的档案先 commit 到版本库避免不必要的冲突事件发生。 在正式进行合并(Merge)之前建议先执行 Test merge 看看是否会发生什么事! 若无异状则可直接按下 [Merge] 按钮进行合并动作这时从 主干 ( /calc/trunk ) 分支出来的到目前工作目录的版本就会做个比较然后直接套用变更到你现有的文件、目录或属性里。 在合并之后如果没有发生冲突不代表真的没冲突所以必须再次对原始码做出验证后才能 commit 进版本库建议可参考以下流程1.将项目进行建置(Build)2.如果没问题再对项目进行单元测试(Unit Testing)或手动测试(Manual Testing)3.如果都没问题再 commit 目前合并无误的版本到版本库 If you encounter serious problems, you can always abort the local changes by running svn revert . 3.合并分支到主干 最后我们的 my-calc-branch 分支已经将新功能开发完成且测试无误所以要将 分支 ( calc/branches/mycalc-branch ) 的最终版本合并回 主干 ( /calc/trunk )这时的手续如下 从 分支 ( /calc/branches/my-calc-branch ) 合并回 主干 ( /calc/trunk ) 通常选第 2 个而特别选择[Reintegrate a branch] 这个选项是很重要的因为这有以下好处1.让 Subversion 能知道 主干 ( /calc/trunk ) 是从哪个分支、哪些版本合并进来的2.有效节省 Subversion Repository (SVN储存库) 的空间因为不用重复储存分支的所有变更信息3.可以产生 Revision graph 得知项目开发的分支状况 一样可以先 测试合并(Test merge) 再正式进行 合并(Merge) 4.合并完后再将变更 commit 到版本库 4.删除使用完毕的分支 当 分支 ( /calc/branches/my-calc-branch ) 合并回 主干 ( /calc/trunk ) 并 commit 了之后该分支就没用了该分支如果未来不再更新或继续开发Subversion 也不会继续追踪这个分支的变更 (因为之前已经Reintegrate 过了)建议将该分支删除。 没有必要继续保留你的私有分支目录。删除已经完成的分支避免其他人继续使用该分支开发减少版本库的复杂程度。 另参考http://www.cnblogs.com/dabaopku/archive/2011/05/21/2052820.html 转载于:https://www.cnblogs.com/InspiringMind/p/4661093.html
