1.SVN版本管理
1.1.资料和方法
ü Subversion版本控制，见http://svnbook.red-bean.com/。 专业介绍SVN的书籍。
ü 官方手册。并不仅仅是手册，原理也介绍很好。
ü 版本管理的目录和管理策略，最好的学习方式是:观察已经非常成熟的svn管理的开源代码。比如brantch就是从某个主干目录独立出来，开发新的，目前主干目录不需要的功能的。
1.2.SVN的划分
以前划分SVN，总是根据开发、研究 、测试等划分，认为开发是中间过程有效的，其他是无效的。这个在实际应用中，有许多问题。主要是因为没有从根本上解决问题，应该分为两类svn。
1、一类是中间过程无效的命名为work_temp。对于work_temp,对于那些不能去确定是否有用的部分，应将其放入legacy目录中。对于确定永久无用的部分，应该删除。一般流程是，首先放入legacy，时间长确定无用时，将其删除。称之存储备份。
2、一类是中间过程有效的命名为work_xx,比如work_VR。称之为版本控制。
3、对于其他部分，首先放在work_temp，工作结束后放入WorkOther中。
1.2.1.只有可测的代码才有版本控制的必要性
只有可测的代码才具有版本控制的必要性，因为无法验证是否正确的代码，没有必要存为一个版本。这也要求我们在工作中，能够将一个大的可测系统，分割为多个小的可测系统。在构建不可测系统中，没有必要加入版本管理中，如果需要中途保存东西，则可将其放入临时SVN中。
构建过程是否有必要加入版本控制中？一个重要的问题就是，每个可测的小系统是否必要必要纳入版本控制中。我的观点有必要，只有是可测的。很明显，以前的工作方式是有问题的，需要更进一步改进。
模块划分，一定是可测的。版本控制，其实版本控制和软件工程师密切相关的，值得思考。
1.2.2.创建自己技术积累的SVN
感觉应该有自己的技术积累的SVN，这部分的代码和算法是自己总结和加工出来的，也可能不止用在一个项目上，即可能反复使用，所以应该单独提出来不断的进化。以前这部分代码在code_study，code_study存在的已有的开源的代码的学习注释和资料，不适合这种代码的存在。对于不能完整实现一个功能的代码，应该放在文档中，不应该以代码的形式积累。所以可将命名为common。
1.2.3.SVN只能按项目划分
SVN只能按项目分，不能按技术分。因为这不符合具体的应用。
1.2.4.SVN分配的再思考
关于SVN中如何区分研究和开发的区分问题。以前将工作分为Research和Temp，似乎在使用过程中不是很好用。现在修改WorkOther和WorkTemp，平时的工作都在WorkTemp进行，如果感觉有保存的必要，则在WorkOther保存必要的版本。这样SVN就包括了经常使用的专用SVN，比如VR等。还有比较杂的通用的SVN比如WorkOther。
1.2.5.以时间为单位对WorkOther进行管理
以时间为单位整理SVNOther的内容和资料于brantch。
1.3.单版本控制思路
双版本机制过时了，因为在排除错误时，逐个版本对比时，版本的跨度太大。以前采用两个版本控制库的策略，A用来备份，B用来存储特定的版本。其中B版本之间的差别太大，不利于查找和定位错误。具体应该是A和B合并为C。其中A部分位于目标trunk，B部分位于tags。其中B部分用于粗略定位,A部分用于精细定位。
如果没有特别提及的，单版本和双版本都适用。
1.3.1.单版本控制的实质是工作计划
1.4.SVN提交
1.4.1.如何确定版本提交工作集
那么如何确定提交工作集，有如下几点体会。
每次测试的工作量。称之为可测工作集。确定可测工作集的原则很简单:如果出了问题，可以迅速定位问题。可以认为其为根据修改代码位置、修改代码属于同一个算法体系、工作性质等划分的代码修改集合。
1.4.1.1.如何判断中间过程是否有用？
版本控制的问题。如何判断中间过程是否有用，可有具体的操作方法。这是自己在实践过程中碰到的问题，一直没有好的办法。
1、必须是跑通的。中间没有跑通的代码，是没有结论的代码，保存其毫无意义。
2、必须是经过严格测试验证的。
1.4.2.不上传多余文件:尽量使用全局忽略样式
如果已经上传了咋么办？利用svn删除即可，记住一定是利用svn，而非直接删除。
1.4.3.不上传多余文件:书写删除脚本
所谓干净提交，就是提交到版本库的内容没有多余的内容，比如obj文件、lib文件、dll文件等。提交前应该将这些文件删除。应该删除如下文件。
具体格式如下:
| rmdir /s/q bin del /Q *.lib //返回到bat所在目录。 //便于脚本以统一的方式书写。 cd .. cd .. cd tools |
组织方式如下:
具体详见全景编码和全景播放器项目。
外部库(lib,dll,so等，比如opencv、matlab等)的处理方式
上传vc工程时的注意事项
1.4.4.lib库是否上传
关于lib文件夹的问题。如果lib，里边放的里lib文件，但只放第三方的lib文件。如果是当前工程生成的lib文件，应该和exe或DLL放在一个文件夹中。
如何在版本控制中区分第三方lib库和程序生成的lib库？第三方lib库是应该上传的，而自我生成的lib库是不用上传的。似乎没有更好办法，可以将其集中在一个目录(比如lib目录)中，集中添加上传。
关于如何上传外部lib库和dll库的问题。
1、外部的dll和lib集中存放在一个目录X。
2、进入目录X，SVN提交。如果无法提交，去掉SVN忽略类型*.lib和*.dll。
1.5.SVN日志
1.5.1.在svn中如何修改日志信息
在服务器端的hooks目录下，建立文件pre-revprop-change.bat,输入如下内容。
@ECHO OFF
REM 限制日志文件的个数采用修改项目属性的tsvn:logminsize，不在脚本中限制
REM 参数
set repos=%1
set rev=%2
set user=%3
set propname=%4
set action=%5
REM 设置超级用户，超级用户可以修改其他人的日志，其他人只能修改自己的日志
set superUser=ygq
REM 只允许日志svn:log的修改
if /I not '%propname%'=='svn:log' goto ERROR_PROPNAME
if /I not '%action%'=='M' goto ERROR_ACTION
for /f "usebackq" %%k in (`svnlook author %repos% -r %rev%`) do @set var=%%k
set rightUser=0
if "%3" == "%superUser%" set rightUser=1
if "%3" == "%var%" set rightUser=1
if %rightUser% == 0 goto ERROR_USER
goto :SUCCESS_EXIT
:ERROR_USER
goto ERROR_EXIT
:ERROR_PROPNAME
echo 只有日志信息能被修改 >&2
goto ERROR_EXIT
:ERROR_ACTION
goto ERROR_EXIT
:ERROR_EXIT
exit 1
:SUCCESS_EXIT
exit 0
然后，右键指定的版本→编辑日志信息。
1.5.2.vs2015下svn的版本信息写入dll或exe
可以用svn相关的命令将版本信息写入库或可执性文件中,这样,在出现bug时,可以很准确的定位版本信息。
1） 添加编辑版本资源。右击-add-resources-version，创建一个version资源。点击resource view，即可按要求编辑。编辑后另存为resource_templet.txt。
2） 配置项目的Resources属性。右键-属性-Resources-General。
3） 设置版本号。编辑set_ver.txt。
| ::$WCREV$,当前最新的提交版本号，详见svn文档的SubWCRev命令 set encoder_ver=2.1.1.$WCREV$ |
4） 替换版本号。书写bat文件version.bat
| ::用set_ver.txt生成set_ver.bat,注意$WCREV$，替换为最新的版本号，比如786 SubWCRev ..\ set_ver.txt set_ver.bat ::用resource_templet.txt替换rc文件，包括版本号 SubWCRev ..\ ..\build\resource_templet.txt ..\build\libpng.rc |
5)编译
| call set_ver.bat @REM 编译libpng.dll cd ..\build msbuild libpng.vcxproj /t:Rebuild /p:Configuration=Release /p:Platform=win32 msbuild libpng.vcxproj /t:Rebuild /p:Configuration=Debug /p:Platform=win32 |
1.5.3.没有必要记录目录和版本信息
svn上已经记录了提交的时间、目录、前一个版本。所以没有必要记录。
右键显示-显示日志。右键版本-浏览版本库和与前一版本比较差异，在所有的差异文件中，目录完全相等的部分即为版本目录。一般情况下为深入具体的目录，查找版本。所以这个记录的意义不大。
1.5.4.单版本模式下:根据工作计划书写日志
以前书写日志，都是自己想出来的，或感觉可以的，没有经过实践的检验，也没有需求驱动的因素，所以缺乏实用性。所以确定根据工作计划书写日志。
仅仅书写计划最底层的项(project中的任务，即任务树中的叶子任务)。其间的关系在project文件中体现，不体现在日志中。
以前曾经提到过，应该将底层任务写入日志中。但没必要每次都将其写入，一开始写入即可，但必须比较容易的检索到。SVN中日志不提供文字的格式，但可以在底层任务前加10个星(*)号，以便于识别。日志一开始就是十个星号(*)和任务名称。比如
**********书写ROI源码
1、书写源码。
2、重构。
1.5.5.日志首先应写需要满足的需求
在书写日志时，应该首先概述满足了什么需求。比如。
1、解决了…的问题。
3、将…记录进文档
4、重构…的代码。
…等等。
然后再详细说明。
1.6.SVN版本合并
1.6.1.操作步骤
具体操作步骤如下。
1) 在目标文件夹上点右键，如要将“branches/工行版”分支的内容合并到主干上，则在“trunk”文件夹上(进入trunk文件夹或选择trunk文件夹)点右键，选择“Tortoise－合并…”。
2) 在弹出窗口选择“合并一个版本范围”（常用选择）。
3) 点击“下一条”。
4) 在“合并的源URL”处选择要合并进来的分支地址，如：http://10.50.22.35:8080/svn/软件中心/project/branches/工行版。
5) 在“待合并的版本范围”处填入合并的版本范围，可点击边上的“显示日志”选择版本。
6) 点击“下一条”。
7) 合并深度选择默认的“工作副本”。
8) “比较空白字符”、“忽略空白字符的变化”等选择用于对文本文件的比较。
9) “测试合并”可在正式合并之前测试合并结果，比如是否存在冲突等。
10) 点击“合并”。
11) 若未发生冲突，可在合并后执行“提交”操作。
12) 若合并时发生冲突，通常可在弹出窗口选择“以后解决”，在本地副本中冲突的文件处将增加2个文件（对二进制文件）或3个文件（对文本文件）。
13) 手动解决冲突后，使用“Tortoise－已解决的”标记冲突已解决，然后执行“提交”操作 。
没有冲突的话，合并后应该在主干的这些修改过的文件上显示红色感叹号，那么你不就需要提交这个主干了吗？
1.6.2.合并选项
合并深度：
1) 工作副本：即你当前的工作目录，一般默认为这个选项。
2) 全递归：即你选择的目录的版本库，包括了其下面的子文件，子文件夹，包括子文件夹里面的内容。
3) 直接子节点，包括文件夹：即你选择的目录下面的文件，文件夹，但是不包括文件夹里面的子文件，子文件夹。
4) 仅文件子节点：即你选择的目录下面的文件，但不包括文件夹，当然不包括的文件夹下面的所有内容也都不纳入合并范围。
5) 仅此项：没有任何合并内容。
1.6.3.如何在学习中合并注释
问题描述。令基础版本为A，在A上添加注释形成版本B；在A上进行其他修改形成版本C。先将B中的注释合并到C中。
1) 选中服务器目录。右键点击TortoiseSVN→在此创建版本库，点击创建目录结构。
2) 选中svn客户端目录。右键点击更新。
3) 进入trunk目录，将版本A的内容，拷入trunk。然后提交。即Trunk_A版。
4) 为版本A建立一个分支Branch_A。如果版本A的所有内容在xxxA下,则branch的目录为/brantch/xxxA。
5) 将branch_A替换为版本B，提交。即Trunk_B。注意在替换时，拷贝覆盖即可。不要在svn中添加B有A没有的文件。
6) 将Trunk_A替换为版本C，提交。即Trunk_C。在替换时，删除A中文件，再将C中文件拷贝到A的位置。这样A中有，而C没有的文件就不会存在于版本C中。提交，选择那些删除掉的文件。
7) 进入Trunk_C目录，进行合并指定的版本范围(详见)。注意在Trunk_B版本中选择版本范围，只有需要合并的修改才被选中。选择忽略所有空白字符。
8) 处理合并过程中出现的冲突。一般而言，选择Trunk_C版本的修改。形成合并后的版本merge_C。注意在目标的svn版本,不要直接在文件层面直接解决冲突,而应改打开文件逐个选择冲突；否则svn将选择整个文件进行替换，而非仅仅冲突的内容。
9) 利用beyond compare比较版本C和版本merge_C。如果其C，C++，C#，汇编以及其他代码完全相等，忽略行尾、空格、空白、注释等；即基于规则的对比，结果为≈。具体详见Beyond compare。
1.7.SVN分支
1.7.1.什么情况下使用分支
分支的另外一个价值。同时开发多个功能时，可以使用分支。比较重要的，以后可能一定用到的功能的，在主干上继续开发。其他的在分支版本上开发。
如果内容变化较多，需要大一个标签，标明一个里程碑。也是版本号变化较大的一个。比如版本1变化到版本2。其中版本2仍然在主干开发，如果需要1继续开发，则只能在分支进行开发。
研究代码话文档。如果是和正式SVN相关的，在工作一个里程后，必须将其上传到正式SVN的brantch。但其研发过程必须在research中，因为其中间过程没有意义。其他的的都放在research中。
1.7.2.如何创建分支？
svn中建立分支的注意事项。需要将目录A建立一个分支。
1、进入到目录A中。注意一定是进入目录A，而非在目录A选定目录A。
2、右键->SVN->分支/标记。
3、弹出一个对话框:在至路径选择/brantches，在后面添加不存在的分支的目标路径比如:/brantches/VR_encode_multithread
注意/brantches/VR_encode_multithread和/brantches/VR_encode_multithread/是有区别的。如果是/brantches/VR_encode_multithread，所有的内容直接写入目录中。如果是/brantches/VR_encode_multithread/所有的内容写入/brantches/VR_encode_multithread/1189中，其中1189位版本号。个人推荐前一种，不妨实验测试一把。
4、在日志信息中填入日志。
5、在从此复制到版本库中，选择需要复制或拷贝的版本。可以是以前的版本，也可以当前版本或工作副本。
1.7.3.利用分支集中存放非正式的开发代码
关于svn集中存放的问题。有利于查找。尽管许多非正式的代码在临时的SVN中，但告一个阶段后，还是必须放到正式SVN中的分支中。
1.8.SVN里程碑版本号及tags
1.8.1.版本号思考1
查了许多资料，tags目录有两个特点:只读+里程碑的版本。
谈谈tags中的里程碑版本。令版本为a.b.c。仿照python的版本策略，总结如下。
1、发布已经使用的。
2、当整体结构发生变化时，a发生改变。比如opencv1.b基于C，opencv2.b基于c++，opencv3.x相对于2.x结构做了重大调整。又比如基于NV的硬编码，如果基于开源代码7.0开发，令为版本1.b，基于开源代码8.0开发的，令为版本2.b。
3、如果代码功能功能发生了改变时但结构没有大变时，应该体现在b上，比如1.0,1.1,1.2。
4、如果功能没有改变，只是清除了bug，应该体现在c上，比如1.0.1,1.0.2等。
5、打tags时，尽量排除所有的bug。
6、开发一个阶段后，以后长时间不在理睬的，作为一个里程碑版本。如果功能增加，体现在b上，否则体现在c上。
7、如果正在开发2.0版本的东西，突然1.x也需要继续开发，那么1.x应该放在分支上开发，因为其是过时的软件系统。比如该github上的opencv就属于这种策略，4.x在主干上开发，3.4.x和2.4.x仍然在分支上开发。非常值得学习。
可以参考github上的源码管理。比如opencv、ffmpeg等。
1.8.2.版本号思考2
版本的又一次思考。a.b.c，比如3.4.14。a:删除已经确定的技术算法或方案，向下没有兼容性。比如1.x的外部调用代码，不一定能使用2.x的库。b:不能删除已经确定的技术方案和算法，但可以增加更好的技术方案或算法。2.1的调用代码可以调用2.3的库，其a相等的条件下，其具有向下的兼容性。c:仅仅是对现有的算法进行修改和完善。比如OpenCV和python似乎都使用的这种思路。
1.9.SVN回滚
点击SVN->显示日志->右击显示的版本。有一个对话框，有三个选项:更新项目至版本，复原到此版本，复原此版本做出的修改。假设当前最新版本为5，右键点击的版本为3。
1.10.其他
1.10.1.引用外部库
1.10.2.修改开源代码的开发方式
基于开源代码开发时，比如基于ffmpeg。只修改了其中少量的代码和文件，在svn上传时，只上传修改的文件。或上传所有的开源文件。搜索了好长时间，没有类似的问题。感觉还是应该上传。但应该做好两个方面的工作。
1.11.基于开源开发多余文件的问题
基于开源代码(比如ffmpeg)开发时，程序实际运行所需要的代码远远小于开源代码的量，如果上传的话，将大大浪费资源，如何处理这个问题呢？
注意事项:上传的文件不仅仅是被修改的文件，而且包括运行程序所需要的所有文件。
1.12.legacy:双版本机制
1.12.1.提交的时机
在开发过程了，为了防止错误或其他原因，仍然需要开发的中间版本，需要频繁的上传以保留。但这种版本在以后的错误查询和开发参考上毫无意义。所以，开发时应该在临时svn下。开发过程使用。如下两种情况同时成立，再上传到svn。
1.12.2.临时(A)svn向正式(B)svn提交流程
1 )删除原有所有的部分。一定是物理删除，切不可用svn删除。主要目的是为了避免混杂。
2)将上传的部分从临时svn拷贝到正式svn。
3）删除无用的东西，利用svn添加，以避免遗漏。右键-svn-增加。
4）上传。上传时一定要点击已经版本控制，以删除已经不存在的问题。
5）彻底删除，然后更新。
6）检查和编译。
7）最后的核查。
2.目录管理
2.1.目录划分的原则
关于项目目录的划分的原则。目录的概念就是一个层次的概念，如果一个层次有足够多的内容，就应该划分更多的子层次进行容纳。不要将目录划分固定化，一定要实事求是，具体情况具体分析。
2.2.划分参考
2.2.1.SVN目录划分
关于SVN目录划分，今天又想出一种目录效率较高的划分方式。具体如下:
这样的目录又少了一层，使的使用更加方便。server也和client放在一个目录里，比较容易管理。
2.2.2.开发目录
2.2.3.研究目录
2.3.readme文件的命名和位置
以前有过这个方面的讨论，但感觉不是很合适。readme用于记录和代码相关的操作层面的内容。比如来源、下载、编译、使用等。主要分为两部分，原来有的readme和自己后加的readme。对于自己后加的readme，应放入目录study_doc/work_doc。如果没有study_doc/work_doc,命名为readme_study或readme_work,以表示是自己的readme，而不是原有的。
对于自己设计的代码，readme应该位于doc中。应该将readme作为文档的一部分。
2.4.区分x86/x64 release/debug
利用目录区分x64和x86，以及release和debug，这个比用符号区别更加符合实际应用。
2.5.项目依赖目录划分
关于项目间依赖的目标关系。如果 A依赖B，那么B应该在A的目录中。如果A和B依赖C，那么C应该在AB之外的公共目录中，具体情况具体分析。
2.6.代码分析的目录划分
3.资料收集管理
3.1.分类问题
在收集资料时，特别的专业的资料，不应该放在语言分类中，而应该放在专业分类中，因为其专业属性更加强一些。比如关于python的贝叶斯分析书籍，应该放在概率的分类中。
书籍选择的两大原则，经典和稀缺。许多中文书籍，虽然不是十分的经典，但写的内容比较专业和偏生，所以也有选择的必要。
3.2.时间标记问题
资料收集时间标记。在上次收集完后，应该在目录名上表明时间，比如201806。下次收集时，按出版时间前推0.5~1年进行。比如下次只收集2017年6月后出版的书籍。
3.3.资料备份原则
4.github
4.1.文献综述
据说版本控制工具要使用git了，收集了几本相关的书籍。现评论如下:
0、入门的第一步书:<>非常适合入门。
1、<>,以软件开发为中心，讲述git的使用。
2、Git高手之路。显然是一些高级主题，不适合入门。
3、<<精通git(第二版)>>介绍了若干主题，可以作为手册查阅。
4、<>，个人感觉介绍的比较散，不值得深究。
5、<>介绍的比较细，值得研究。
从上面可以看到，一开始学习，0、1和5是比较值得推荐的。
4.2.注意事项
5.其他
5.1.阅读电子书时，没有需求的情况下，不升级版本
因为在以后，要在电子书上做一些记录和注释，如果更新新的版本，这些记录和注释意味着更新或丢失，非常的耗时费力或损失一些信息。
知识也有灵魂？其实就是将所有的点串起来的那条线，其实就是其使用流程。
5.2.硬件相关的代码，注意代码的版本不能太新
硬件相关的代码，采用尽可能的低的版本。因为高版本可能不支持以前的硬件设备。比如NVIDIA硬编码。
5.3.版本管理的问题:保留一份
关于版本管理的一个问题：在将开发内容移交到正式版本后，删除原有的临时开发内容，严格遵守只保留一份的原则。同时留的东西太多，容易冗余。如何严格区分科研和开发的界限？对码流的处理，应该属于研究的范围，因为没有现成的方案。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
