软件工程-SVN版本控制和目录管理

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.单版本控制的实质是工作计划

  每一次代码修改都是个人可控的一个工作单元。这个工作单元的大小因人而异，比如控制力强的人，工作单元可以大一些，控制力弱的人，工作单元必须小一些。每一次代码修改都必须是可测的，并且必须是测试成功的。想不到版本控制竟然和工作计划相关，实在是技高一筹。

  版本控制是工作计划的具体体现，每一个版本都是工作计划的一步。在工作中，将工作计划、版本控制、单元测试融为一体。所以，版本的日志，就是你的工作计划书，应该将日志内容和工作计划内容统一起来。不仅有具体的内容，而且要注意日志的层次。如何记录日志的层次，又待进一步明确。

  一个svn版本库应该是一个工作提交单元。比如硬编码器，软编码器等。

  tags应该是正式发布的版本或一个比较完备的 大的工作单元。

1.4.SVN提交

1.4.1.如何确定版本提交工作集

那么如何确定提交工作集，有如下几点体会。

每次测试的工作量。称之为可测工作集。确定可测工作集的原则很简单:如果出了问题，可以迅速定位问题。可以认为其为根据修改代码位置、修改代码属于同一个算法体系、工作性质等划分的代码修改集合。

  所提交的中间过程必须是有价值的。

  提交的工作集必须是自己可控的。所谓可控，可以用可测工作子集确定。其数目应该<=5。最好是2~3个。因为太多的可测工作集，不利于未来bug排除问题的定位。在开发中，太大的提交工作集，出了问题无法恢复或损失太多。

  所有的工作属于同一类型的工作。不能把算法代码的书写和重构放在一个提交工作集中。

  一个提交工作集可以包含多个测试。一个测试不能有两个提交工作集。

1.4.1.1.如何判断中间过程是否有用？

版本控制的问题。如何判断中间过程是否有用，可有具体的操作方法。这是自己在实践过程中碰到的问题，一直没有好的办法。

1、必须是跑通的。中间没有跑通的代码，是没有结论的代码，保存其毫无意义。

2、必须是经过严格测试验证的。

1.4.2.不上传多余文件:尽量使用全局忽略样式

如何在上传时，不上传多余的文件。首先从上传前进行准备工作。

  将从其他文件生成的文件集中存放在一个目录，以便集中删除。

  在SVN中设置全局过滤样式，上传前，右键-添加即可。

  将lib和dll库写入整体忽略模式，以和公司的SVN版本库保持一致。有两种库，一种是从外面引入的库，必须在文档中加以说明，库的名称，版本号等。一种是内部库，编译时指明依赖关系即可。

如果已经上传了咋么办？利用svn删除即可，记住一定是利用svn，而非直接删除。

1.4.3.不上传多余文件:书写删除脚本

所谓干净提交，就是提交到版本库的内容没有多余的内容，比如obj文件、lib文件、dll文件等。提交前应该将这些文件删除。应该删除如下文件。

  可以从其他文件生成的文件。

  外部引入的lib、dll库文件。

具体格式如下:

cd ..             //进入需要删除文件的目录 rmdir /s/q bin cd lib\           //进入需要删除文件的目录 cd x64\           //进入需要删除文件的目录 del /Q *.lib //返回到bat所在目录。 //注意必须这样。保证下一次删除的其实目录是同一个目录 //便于脚本以统一的方式书写。 cd .. cd .. cd tools

组织方式如下:

  每个大的工程目录里书写一个bat，在外部调用其bat执行删除功能。

  注意调用时必须使用call命令，否则无法返回到控制台。

具体详见全景编码和全景播放器项目。

外部库(lib,dll,so等，比如opencv、matlab等)的处理方式

  不在svn提交的范围内。

  在源码学习目录中备份。

上传vc工程时的注意事项

  对于vs2010而言，保留所有的*.sln,*.vcxproj,*.vcxproj.filter,*.vcxproj.user。

  对于vs2008，保留所有的*.sln和*.vcproj,*.vcxproj.filter,*.vcxproj.user。

  对于vs2015而言，filters文件涵盖了目录划分的信息，不能删除。

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

REM 只允许修改日志，增加、删除等操作不允许

if /I not '%action%'=='M' goto ERROR_ACTION

REM 只允许用户修改自己的日志

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

echo 只允许用户修改自己的日志 >&2

goto ERROR_EXIT

:ERROR_PROPNAME

echo 只有日志信息能被修改 >&2

goto ERROR_EXIT

:ERROR_ACTION

echo 只允许修改日志，不允许增加、删除等操作 >&2

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、解决了…的问题。

2、增加了…的功能。

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。

  更新项目到此版本:当前工作副本为版本3，当前工作副本为版本3(粗体显示)，最新版本仍然为5。如果版本4~5仍然在下一个版本中，仅仅临时使用一下版本3，则使用更新。

  复原到此版本：当前工作副本内容为版本3，当前工作副本为版本5(粗体显示)，最新版本为5。如果下一个版本中，不需要版本4~5的修改，则使用复原。

  复原此版本作出的修改：只适应于最近的一个版本，否则将产生冲突。这个操作目前没有暂时不用，不予关注。

1.10.其他

1.10.1.引用外部库

  必须在相关文档中说明。包括库的名称、版本号、来源等。

  也可以将外部库直接上传SVN。不过这个不提倡，因为有的库确实很大，太占有资源。

  外部库的相关代码和文档必须在个人电脑的code_study中有。

1.10.2.修改开源代码的开发方式

基于开源代码开发时，比如基于ffmpeg。只修改了其中少量的代码和文件，在svn上传时，只上传修改的文件。或上传所有的开源文件。搜索了好长时间，没有类似的问题。感觉还是应该上传。但应该做好两个方面的工作。

  尽可能删除不用的代码。

  记录开源代码的名称和版本号。

  采用patch的方式，即SVN中的补丁方式。在github中的Immersive-Video-Sample中采用的就是这种模式

1.11.基于开源开发多余文件的问题

基于开源代码(比如ffmpeg)开发时，程序实际运行所需要的代码远远小于开源代码的量，如果上传的话，将大大浪费资源，如何处理这个问题呢？

  手动删除无用的文件。

  采用SVN补丁。

注意事项:上传的文件不仅仅是被修改的文件，而且包括运行程序所需要的所有文件。

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目录划分，今天又想出一种目录效率较高的划分方式。具体如下:

  Trunk

  Brantch

  Tags

  Sever:用于存放SVN服务器。将其作为隐藏的项目，如果需要在win10中显示隐藏的的项目。

这样的目录又少了一层，使的使用更加方便。server也和client放在一个目录里，比较容易管理。

2.2.2.开发目录

  dependency:依赖的子项目。

  external:依赖的外部库和头文件。

  bin:输出的地方。

  doc文档。

  build:工程所在目录。

  research:用于当前工程的自研算法。

2.2.3.研究目录

  reference:参考文献

  doc:研究文档。

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.代码分析的目录划分

  study目录，主要用于书写注释等。

  test目录:用于运行和跟踪代码。

  Orignal:原来的没有修改的代码，主要用于对比和核对源码。

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.注意事项

  在搜索代码时，注意左侧的Brantch，可能有许多分支比如msvc等，对应于不同的应用。

  下载代码时， 默认为master分支。如果切换到其他分支。比如想进入msvc分支。首先进入mater分支，并clone。Git checkout -b child_repos origin/msvc即可。详见http://blog.csdn.net/andypan1314/article/details/17437595。

  搜索代码关键字的问题。在输入多个单词关键字搜索时，不包括多个单词的组合，这一点一定要注意。比如要搜索image quant，其不包括imagequant、libimagequant，需要分别输入搜索。但是包括这样的单词，比如quant包括quantization。

5.其他

5.1.阅读电子书时，没有需求的情况下，不升级版本

因为在以后，要在电子书上做一些记录和注释，如果更新新的版本，这些记录和注释意味着更新或丢失，非常的耗时费力或损失一些信息。

知识也有灵魂？其实就是将所有的点串起来的那条线，其实就是其使用流程。

5.2.硬件相关的代码，注意代码的版本不能太新

硬件相关的代码，采用尽可能的低的版本。因为高版本可能不支持以前的硬件设备。比如NVIDIA硬编码。

5.3.版本管理的问题:保留一份

关于版本管理的一个问题：在将开发内容移交到正式版本后，删除原有的临时开发内容，严格遵守只保留一份的原则。同时留的东西太多，容易冗余。如何严格区分科研和开发的界限？对码流的处理，应该属于研究的范围，因为没有现成的方案。