如何在MAC环境下使用svn,以及新手在团队使用svn注意事项
1、Xcode4中苹果有自带的SVN软件------>Organizer------>Repositories
2、SVN checkout到本地后,删除本地file,对服务器有影响吗
不会影响服务器,当你执行“svn update”时会zai再次被自动下载;当删除后再执行“svn commit”就会在服务器上也对应删除。
3、连接服务器
点击file-》repositories-》点击坐下边的“+”-》然后名字及svn服务器的地址,还有type选中subversion然后next等等了。
4、Xcode4下,SVN中常用命令
Commit 提交
checkout 将服务器上下载到本地(我个正在使用的电脑)
update 更新文件
File------->SourceController------->update
中第3个按钮,是视图对比按钮
5、SVN中用法详解和注意事项
①提交自己的代码
SVN更新的原则是要及时更新,及时提交。当完成了一个小功能,能够通过编译并且并且自己测试之后,尽量早的提交,这样也保存了历史版本,必要时候可以回滚;在开始一天的工作之前,最后update一下项目。
②保持原子提交(不要不经意间修改并提交了别人的文件)
仅提交你修改的部分,最好不要一下子将整个项目提交;
当完成一个功能或文件后,最好提交。我就遇到完成某个功能后,没有提交,后来又做了更改,结果代码出现bug,无法恢复到正常时的代码。
③不要提交自动生成的文件
VisualStudio等开发工具在生成过程中会产生很多自动文件,如suo等配置文件,Debug,Release,Obj等编译文件,以及其他的一些自动生成,同编译代码无关的文件,这些文件在提交的时候不应该签入,如果不小心签入了,需要从仓库中删除。
④不要提交不能通过编译的代码
代码在提交之前,首先要确认自己能够在本地编译。进行SVN提交更新时最好是代码在提交前已经通过自己的测试。
SVN中常用命令详解
1、将文件checkout到本地目录
svn checkout path(path是服务器上的目录)
例如:svn checkout svn://19216811/pro/domain
2、往版本库中添加新的文件
svn add file
例如:svn add testphp(添加testphp)
3、删除文件
svn delete path -m “delete test fle“
例如:svn delete svn://19216811/pro/domain/testphp -m “delete testfile”
4、查看日志
svn log path
5、比较差异
svn diff path(将修改的文件与基础版本比较)
6、将两个版本之间的差异合并到当前文件
svn merge -r m:n path
SVN使用方法
更新(update),经常地update没有坏处,特别是多人项目中。如果每次提交(commit)前不进行更新(update)的到最新的版本的话,svn会提示当前的拷贝过期,需要更新。
提交(commit),一定要写上这次提交的内容的摘要,便于以后查阅。
将文件checkout到本地目录
svn checkout path(path是服务器上的目录)
svn update命令自动用服务器上的版本替换本地版本控制的文件
6、Xcode中使用SVN问题以及提交解决冲突问题
Xcode的SVN功能,和Eclipse中的subclipse或者windows下的tortoiseSVN比较起来功能还差很多。
我是索性不用的,直接用命令行。我看有的朋友是用subclipse,其实也挺好,不过,为了使用SVN功能要单独开一个耗费资源的Eclipse。
但是,不论使用什么SVN工具,都会遇到Xcode固有的问题,即projectpbxproj文件的提交冲突问题。
projectpbxproj文件里面包含了构建过程所需的所有文件,如果你在项目目录下增加了新文件,比如没有通过Xcode,该文件就不在projectpbxproj文件中,就不会生成到app中。同理,如果你从SVN中更新到其他项目成员增加的文件,而没有更新projectpbxproj文件(或者该成员根本就没有提交这个文件),则也会出现相同的现象。
如果项目成员提交了新的projectpbxproj文件,你这边没有在项目中增加新的文件,直接svn update就可以了。
7、Xcode中更新代码后项目文件打不开
若选择更新整个项目经常会出现冲突问题,尤其是projectpbxproj文件。此文件包含了构建过程所需的所有文件,如果在项目目录下增加了新文件,但没有通过Xcode,
该文件就不在projectpbxproj文件中,就不会生成到app中。同理,如果从SVN中更新到其他项目成员增加的文件,
而没有更新projectpbxproj文件(或者该成员根本就没有提交这个文件),则也会出现相同的现象。这一文件冲突将直接导致项目文件打不开。
解决更新代码后打不开项目文件方法:
当项目文件如tobaccoxcodeproj打不开时可以右键选择'显示包内容',会看到有三个文件,projectpbxproj/usermodelv3/userpbxuser。
其中projectpbxproj有三个版本,和解决普通svn文件冲突一样解决冲突即可。
8、SVN 更新 提交 合并 区别
当本地文件没有改动,服务器文件改动的时候,更新会从服务器取文件覆盖当前文件
当本地文件有改动,服务器文件没改动的话,不会更新此文件
当本地文件有改动,服务器文件有改动的话,如果改动的部分不冲突,就会合并文件到本地,如果有冲突的话,会提示文件冲突,需要自己手动修改以后上传到服务器。
最后一个讲解合并:
服务器和本地的同一个文件(所谓同一个文件应该就是SVN相对路径相同,文件名相同的文件,这个由SVN留在本地的信息决定)已经修改,且修改的部分不重合,不重叠
当满足上面的条件的时候再更新,SVN就会自动合并
SVN的奥妙之处就在于别人提交了修改后的文件,你再提交你的话,他是不允许你提交滴。。。
>>>>
<<<
里面标记的是冲突的区域,把冲突区域删除掉为什么还不能提交
解决办法1:
删掉的话还是没有解决冲突,文件后面还会有几个文件名相同,但是后缀不同的文件
如果你不知道用SVN解决冲突的话,最简单的办法是这样的
把这个文件改名字,然后在文件所在目录更新,这样就会把服务器文件下下来,然后把自己修改的部分添加到更新的文件里面,这样就可以提交了
解决办法2:
在文件上面点击右键,到SVN的菜单,应该有编辑冲突的按钮,选择就会出现一个窗口,一边是服务器版本,一边是自己修改的版本 。
9、xcode自带svn的使用
1、代码中 某文件后面有 “M” 标记,表示该文件已被修改,需要 commit
(右键该文件 -> source control -> commit selected file)
2、代码中 某文件后面有 “A” 标记,表示该文件是新添加的,已受SVN管理,需要 commit
(右键该文件 -> source control -> commit selected file)
3、代码中 某文件后面有 “” 标记,表示该文件是新添加的,并且脱离了SVN的管理,首先需要add,然后 commit
(右键该文件 -> source control -> Add,这样该文件的标记就变为 “A”,然后在 commit)
原文:https://wwwcnblogscom/LiuYanYGZ/p/11029552html
1首先将svn的所指定的目录checkout到本地目录下:
使用svn co +服务器的地址(path),输入服务器的密码即可,此时会自动在本地目录下同步服务器你所指定的目录及里面所有的文件(其中co 即是 checkout的简写)
例如:svn co http://svnxxxcom/path
此时在本地目录下就会出现名为path的文件夹
2往版本库中添加新的文件(夹)
将所要上传的文件(夹)复制到svn服务器的指定文件结构目录下,跳转到该目录下然后执行:
svn add +文件名
如,svn add mappy
svn ci -m “ xx” mappy (“”号内加的是文件夹的注释) 或
svn commit -m 'xx' mappy
3上传完成之后,在svn服务器刷新即可看到上传的文件(夹)
Subversion不提供这个特性。Subversion不存放文件各自的修改日期,而是存放它每次提交等事件的时间 。
如果你一定要这样做的话,可以采取下面的方法:
(1) 将文件一个一个的导入, 按照修改时间和日期进行排序存到各自的revision下面。导入文件的时候, 将svn:date属性修改为原文件的最后修改时间。
(2) 在客户端, 你需要使用"use-commit-times" 选项,以便你之后在checkout的时候将最后修改时间修改成当前时间。
可能这样有点麻烦,但是我记得好像网上有人写了些相应的script什么的来批量执行上面的操作,你可以到网上找找看。
不用把文件复制一份到目录下的上传方法(类似把文件上传到网盘):
1、把URL复制到浏览器中,检查网络是不是通的,输入账号密码可以查看目录结构;
出现下图情况则网络不通或者URL错误,注意区分使用内外网的URL。
2、任意文件夹下右键-TortoiseSVN-版本库浏览器,英文版的菜单名称自行翻译。
3、打开版本库浏览器如下,输入已测试可用的URL,点击箭头可查看目录结构,与资源管理器相似。
4、演示上传一个本地文件夹(包含多个子文件夹、文件的)到“数据”目录下
5、在版本库浏览器的“数据”文件夹下右键-创建文件夹,以需要上传的文件夹名称命名。
6、资源管理器中找到需要上传的文件夹,右键-TortoiseSVN-导入,需要注意的是资源管理器中右键导入不会把最高一级的文件夹也导入,因此需要先手动新增最高一级的文件夹,里面的若干个文件夹和文件都会导入进去。
7、点击“浏览”按钮,选择需要刚刚新增的文件夹,点击确定,导入窗中版本库URL显示为需要上传的路径,点击确定。
8、导入显示如下
9、导入成功后版本库浏览器中可看到已上传的文件夹/文件
11、也可以在版本库浏览器的对应目录下直接右键-加入文件/文件夹,浏览选择需要上传的文件/文件夹
这里假设SVN项目的目录为 /data/svn/project,我们想排除trunk/testexe文件和trunk/notallowed/目录,操作步骤如下及执行的svn命令(在svn安装目录的bin目录下)如下:
# 首先将svn库整个导出
svnadmin dump /data/svn/project > project_originaldump
# 然后将project_originaldump文件里面不需要的文件进行排除并生成一个新的dump文件
type project_originaldump | svndumpfilter exclude trunk/testexe trunk/notallowed > project_newdump
# 接下来创建一个新的svn项目并将上面的dump文件导入到一个新的项目中
svnadmin create /data/svn/project_new
svnadmin load /data/svn/project_new < project_newdump
最后将原来的project目录删除并将project_new修改成project即可。需要注意的是dump命令会将svn项目中的所有修改和历史记录都导出来,这样导出的dump文件会很大,而且导入的时间也比较长。
从服务器端彻底删除SVN版本库中部分文件夹或文件
若要彻底删除SVN版本库某一文件夹或文件,可采取这种方法(举例说明):
例:假设SVN库路径为E:/svn/project,库中的目录结构为
QA/Trunk
Software/Tags/testexe
删除Software/Tags/目录下的testexe文件
操作步骤为:
把SVN库dump出来
使用svndumpfilter过滤掉要删除的文件
新建一个SVN库
再将处理好的文件load到新的SVN库里
具体命令为:
>svnadmin dump E:/svn/project > aaadump
>type aaadump | svndumpfilter exclude /Software/Tags/testexe > bbbdump
>svnadmin create E:/svn/project_new
>svnadmin load E:/svn/project_new < bbbdump
然后再将新建的project_new 重命名为project,以前的project可以移走,或是另取一个名称(因为在TRAC中使用的SVN目录是project,用户所使用的SVN目录也是project)
此方法在SVN库里版本不多的情况下完全可以达到彻底删除SVN版本库某一文件夹或文件的效果,但是如果SVN库里的版本过多,在dump版本的时候会因存储空间不足,而无法dump版本.也就无法操作了.这时须另挂能满足其存储空间的硬盘操作
SVN如何恢复已删除文件或文件夹
用TortoiseSVN:
1在本地working copy中,用TortoiseSVN->Show log查看版本库的历史记录。可以用search。
2找到删除该文件或者文件夹的版本,在Log message里右键Revert the changes from this revision。
3该文件或文件夹就被恢复到本地的working copy中了。如果是误删除的,commit到Repository里就行了。
用Eclipse的Subclipse插件:
1用Team->Show SVN Repository History查看版本库的历史记录。
2 找到删除该文件或者文件夹的版本,右键Revert to XX version
3该文件或文件夹就被恢复到本地的working copy中了。如果是误删除的,commit到Repository里就行了。
百万级访问量网站的技术准备工作
当今从纯网站技术上来说,因为开源模式的发展,现在建一个小网站已经很简单也很便宜,所以很多人都把创业方向定位在互联网应用。这些人里大多数不是很懂技术,或者不是那么精通,而网站开发维护方面的知识又很分散,学习成本太高,所以这篇文章将这些知识点结合起来,系统的来说,一个从日几千访问的小小网站,到日访问一两百万的小网站,中间可能会产生什么问题,以及怎么才能在一开始做足工作尽量避免这些问题。
你的网站因为努力经营,访问量逐渐升高,在升高的过程中,问题也可能开始显现了。因为带宽的增加、硬件的扩展、人员的扩张所带来的成本提高是显而易见的,而还有相当大的一部分成本是因为代码重构、架构重构,甚至底层开发语言更换引起的,最坏的情况就是数据丢失,所有努力付之一炬。这类成本支出大多数在一开始就可以避免,先打好基础,往后可以省很多精力,少操很多心。
对于不同的初期投资成本,技术路线的选择是不同的。这里假设网站刚刚只是一个构想,计划第一年服务器硬件带宽投入5万左右。对于这个资金额度,有很多种方案可选择,例如租用虚拟主机、租用单独服务器,或者流行的私有云,或者托管服务器。前两种选择,网站发展到一定规模时需迁移,那时再重做规划显然影响更大。服务器托管因为配置自主、能完全掌握控制权,所以有一定规模的网站基本都是这种模式。采用自己托管服务器的网站,一开始要注意以下几点——
一、开发语言
一般来说,技术人员(程序员)都是根据自己技术背景选择自己最熟悉的语言,不过不可能永远是一个人写程序,所以在语言的选择上还要是要费些心思。首先明确一点,无论用什么语言,最终代码质量是看管理,因此我们从前期开发成本分析。现在国内流行的适用于网站的语言,大概有java、php、net、 python、ruby这五大阵营。python和ruby因为在国内流行的比较晚,现在人员还是相对难招一些。net平台的人相对多,但是到后期需要解决性能问题时,对人员技能的要求比较高。剩余的java、php用人可以说是最多的。java和php无法从语言层面做比较,但对于初期,应用几乎都是靠前端支撑的网站来说,php入门简单、编写快速,优势相对大一点。至于后端例如行为分析、银行接口、异步消息处理等,等真正需要时,就要根据不同业务需求来选择不同语言了。
二、代码版本管理
稍微有点规模的网站就需要使用代码版本管理了。代码版本管理两点最大的好处,一是方便协同工作,二是有历史记录可查询比较。代码版本管理软件有很多,vss/cvs/svn/hg等,目前国内都比较流行,其中svn的普及度还是很高的。
假设选了svn,那么有几点考虑。一是采用什么树结构。初期可能只有一条主干,往后就需要建立分支,例如一条开发分支,一条上线分支,再往后,可能要每个小组一个分支。建议一开始人少时选择两条分支,开发和线上,每个功能本地测试无误后提交到开发分支,最后统一测试,可以上线时合并到上线分支。如果每人都建自己的分支,合并时会浪费很大精力,对于几乎每天都要修改几次的WEB应用来说,所费时间太多。
向服务器部署代码,可以手工部署也可以自动部署。手工部署相对简单,一般可直接在服务器上svn update,或者找个新目录svn checkout,再把web root给ln -s过去。应用越复杂,部署越复杂,没有什么统一标准,只是别再用ftp上传那种形式,一是上传时文件引用不一致错误率增加,二是很容易出现开发人员的版本跟线上版本不一致,导致本来想改个错字结果变成回滚。如果有多台服务器还是建议自动部署,更换代码的机器从当前服务池中临时撤出,更新完毕后再重新加入。
三、服务器硬件
在各个机房里,靠一台服务器孤独支撑的网站数不清,但如果资金稍微充足,建议至少三台的标准配置,分别用作web处理、数据库、备份。web服务器至少要8G内存,双sata raid1,如果经济稍微宽松,或静态文件或多,则15k sas raid10。数据库至少16G内存,15k sas raid 10。备份服务器最好跟数据库服务器同等配置。硬件可以上整套品牌,也可以兼容机,也可以半品牌半组装,取决于经济能力。当然,这是典型的搭配,有些类型应用的性能瓶颈首先出现在web上,那种情况就要单独分析了。
web服务器可以既跑程序又当内存缓存,数据库服务器则只跑主数据库(假如是MySQL的话),备份服务器所承担就相对多一些,web配置、缓存配置、数据库配置都要跟前两台一致,这样WEB和数据库任意一台出问题,很容易就可以将备份服务器切换过去临时顶替,直到解决完问题。要注意,硬件是随时可能坏掉的,特别是硬盘,所以宁可WEB服务器跟数据库服务器放在一起,也一定不能省掉备份,备份一定要异机,并且有异步,电力故障、误操作都可能导致一台机器上的所有数据丢失。很多的开源备份方案可选择,最简单的就是rsync,写crontab里,定时同步。备份和切换,建议多做测试,选最安全最适合业务的,并且尽可能异地备份。
四、机房
三种机房尽量不要选:联通访问特别慢的电信机房、电信访问特别慢的联通机房、电信联通访问特别慢的移动或铁通机房。机房要尽可能多的实地参观,多测试,找个网络质量好,管理严格的机房。机房可以说是非常重要,直接关系到网站访问速度,网站访问速度直接关系到用户体验,访问速度很慢的网站,很难获得用户青睐。
五、架构
在大方向上,被熟知的架构是web负载均衡+数据库主从+缓存+分布式存储+队列。在一开始,按照可扩展的原则设计和编程就可以。只是要多考虑缓存失效时的雪崩效应、主从同步的数据一致性和时间差、队列的稳定性和失败后的重试策略、文件存储的效率和备份方式等等意外情况。缓存失效、数据库复制中断、队列写入错误、电源损坏,在实际运维中经常发生,如果不注意这些,出现问题时恢复期可能会超出预期很长时间。
六、服务器软件
操作系统Linux很流行。在没有专业运维人员的情况下,应倾向于择使用的人多、社区活跃、配置方便、升级方便的发行版,例如RH系列、 debian、ubuntu server等,硬件和操作系统要一起选择,看是否有适合的驱动,如果确定用某种商业软件或解决方案,也要提前知晓其对哪种操作系统支持最佳。web服务器方面,apache、nginx、lighttpd三大系列中,apache占有量还是最大,但是想把性能调教好还是需要很专业的,nginx和 lighttpd在不需要太多调整的情况下可以达到一个比较不错的性能。无论选择什么软件,除非改过这些软件或你的程序真的不兼容新版本,否则尽量版本越新越好,版本新,意味着新特性增多、BUG减少、性能增加。一个典型的php网站,基本上大多数人都没改过任何服务器软件源代码,绝大多数情况是能平稳的升级到新版本的。类似于jdk5到 jdk6,python2到python3这类变动比较大的升级还是比较少见的。看看ChangeLog,看看升级说明,结合自己情况评估测试一下,越早升级越好,升级的越晚,所花费的成本越高。对于软件包,尽量使用发行版内置的包管理工具,没有特殊要求时不建议自己编译,那样对将来运维不利。
七、数据库
几乎所有操作最后都要落到数据库身上,它又最难扩展(存储也挺难)。数据库常见的扩展方法有复制、分片,设计时要考虑到每种应用的数据如何复制、分片,当然这种考虑一般会推迟到技术设计时期。在初期进行数据库结构设计时,要根据不同的业务类型和增长量预期来考虑是否要分库、分区,并且尽量不要使用联合查询、不使用自增ID以方便分片。复制延时问题、主从数据库数据一致性问题,可以自己写或者用已有的运维工具进行检测。
用存储过程是比较难扩展的,这种情形多发生于传统C/S,特别是OA系统转换过来的开发人员。低成本网站不是一两台小型机跑一个数据库处理所有业务的模式,是机海作战。方便水平扩展比那点预分析时间和网络传输流量要重要的多的多。
另外,现在流行一种概念叫NoSQL,可以理解为非传统关系型数据库。实际应用中,网站有着越来越多的密集写操作、上亿的简单关系数据读取、热备等,这都不是传统关系数据库所擅长的,于是就产生了很多非关系型数据库,比如Redis/TC&TT/MongoDB/Memcachedb等,在测试中,这些几乎都达到了每秒至少一万次的写操作,内存型的甚至5万以上。在设计时,可根据业务特点和性能要求来选择是否使用这类数据库。例如 MongoDB,几句配置就可以组建一个复制+自动分片+failover的环境,文档化的存储也简化了传统设计库结构再开发的模式。但是当你决定采用一项技术时,一定要真正了解其优劣,例如可能你所选择的技术并不能支持你所需要的事务和数据一致性要求。
八、文件存储
存储的分布几乎跟数据库扩展一样困难,不过只有百万的PV的情况下,磁盘IO方面一般不会成大问题,一两台采用SATA做条带RAID的机器可以应付,反而是自己做异步备份比较复杂,因为小文件多。如果只有一台机器做存储,可以做简单的优化,例如放最小缩略图的分区和放中等缩略图的分区,根据平均大小调整一下块大小。存储要规划好目录结构,否则文件增多后维护起来复杂,也不利于扩展。同时还要考虑将来扩容,例如采用LVM,或者把文件根据不同规则散列到不同机器。磁盘IO繁重的情况下更容易出现故障,所以要做好备份,若发现有盘坏掉,要马上行动更换,很多人的硬盘都是坏了一块之后,接二连三的坏下去。
为了将来走cdn做准备,一开始最好就将的域名分开,且不用主域名。因为很多网站都将cookie设置到了domainltd,如果也在这个域名下,很可能因为cookie而造成缓存失效,并且占多余流量,还可能因为浏览器并发线程限制造成访问缓慢。
九、程序
一定硬件条件下,应用能承载多少访问量,很大一部分也取决于程序如何写。程序写的不好,可能一万的访问都承载不了,写的好,可能一两台机器就能承担几百万PV。越是复杂、数据实时性要求越高的应用,优化起来越难,但对普通网站有一个统一的思路,就是尽量向前端优化、减少数据库操作、减少磁盘IO。向前端优化指的是,在不影响功能和体验的情况下,能在浏览器执行的不要在服务端执行,能在缓存服务器上直接返回的不要到应用服务器,程序能直接取得的结果不要到外部取得,本机内能取得的数据不要到远程取,内存能取到的不要到磁盘取,缓存中有的不要去数据库查询。减少数据库操作指减少更新次数、缓存结果减少查询次数、将数据库执行的操作尽可能的让你的程序完成(例如join查询),减少磁盘IO指尽量不使用文件系统作为缓存、减少读写文件次数等。程序优化永远要优化慢的部分,换语法是无法“优化”的。
然而编程时不应该把重点放在优化上,应该关注扩展性。当今的WEB应用,需求变化非常之快,适应多种需求的架构是不存在的,我们的扩展性就要把要点放在跟底层交互的架构上,例如持久化数据的存取规则、缓存的存取规则等,还有一些共用服务,例如用户信息等。先把不变的部分做完善,剩下的部分就很容易将精力放在业务逻辑上面了。
0条评论