代码版本控制
冲突的话可以分为几种情况，这里随便说几种，列举的可能不全，还有可以追问。
首先根据代码管理器的情况，确定是否支持多签出，如果不允许，那就基本可以确定是冲突1（说明：由于本地版本与服务器版本不同，导致获取服务器版本时的冲突。该冲突多见于多人开发且分工不明确的VSS中）；如果允许多签出，获取文件或者签出时会出现冲突1相同的问题，还有可能是签入时的冲突2（说明：由于修改前版本与服务器端版本不一致导致冲突产生。该冲突多见于SVN服务器或特殊设置的VSS服务器）；这两种情况之外，还有CM对代码分支进行合并等操作导致的冲突，这种冲突是必须的，而且大部分需要手动处理，算是冲突3。
『贰』 如何为VS2010添加版本控制
网络搜索 Visual Source Safe 2005 安装文件，下载并保存。
2，运行setup.exe文件
3，按照步骤执行安装，默认安装配置即可
4，安装完成
5，注意！！！这里要以管理员身份运行Microsoft Visual SourceSafe
6，进入设置向导，点击下一步
7，选择简历一个新的database
8，任意选择一个文件夹来存放数据库数据，点击下一步，然后任意输入数据库的名称
9，选择-Modify-Merge-Model，点击下一步，然后点击完成
10，打开VS2010,选择工具——选项——源代码管理——下来列表中选择（当前源代码管理插件）Microsoft Visual SourceSafe——确定
11，打开现有解决方案，选择文件--源码管理--将解决方案添加到源代码管理，即可
『叁』 如何把程序代码和数据库一起加入版本控制
那最好把每次修改的内容都保留在脚本里面,以前的代码不删除,不要的就注释起来,并且加上时间标记,你看看这样可否满足？版本控制的软件挺多的vss,cvs,preforce等等,但个人都觉得不好用,没有这种方法直观
所有数据库脚本 按照普通程序一样保存为项目 代码
更新数据库 就更新脚本 或者增加脚本 作为增量/修改 标志
任何版本控制软件都可以 做到
我们公司已经用了我说的方法， 为了 做 增量升级
你的脚本还必须 分好 结构 或者写好一点 执行脚本，方便 执行 全 部署 和增量 部署 。
包括 数据结构 授权 特殊数据更新 存储过程 触发器 等等
就算你现在只有存储过程，难以保证以后没有其他的。
『肆』 版本控制在软件开发中由谁管理
svn版本控制器安装 分类:学习园地Subversion 系统
多年来，并发版本系统（CVS）一直是在Linux上管理代码或者文本的标准。作为基于RCS上建立但却允许多用户协作的系统而言，CVS记录所有文件的修改信息。这对于程序开发者、网络设计者和系统管理员而言，是非常有用的。
然而，CVS逐渐显示出它的衰老，出现了相似的源代码管理软件。然而大多这种东西都是以牟利为主要目的的。
Subversion就是一种相对新鲜的源代码管理系统。虽然事实上它还在不断的反展之中，但是Subversion已经是一个非常稳定而且成熟的产品。它是一个全新的系统，其功能可以和CVS媲美，同时，它要比CVS更直观，更容易操作。本文就Subversion的安装和一些特殊功能作一个介绍。
安装服务器端
第一步：下载Apache和SVN源码包
从官方网站台下载httpd-2.0.52.tar.gz,subversion-1.2.3.tar.gz
(因为redhat 9默认安装的Apache没有并包含--enable-so选项，所以无法产生mod_dav_svn.没有这个模块，SVN就无法采用http方式运行，所以必须重新编译新的Apache)
以root身份执行：
#tar zxvf httpd-2.2.0.tar.gz
#cd httpd-2.2.0
#./configure --enable-dav --enable-so --enable-maintainer-mode
#make
#make install
此时会产生/usr/local/apache2目录,接着执行:
#tar zxvf subversion-1.2.3.tar.gz
#./configure --with-apxs=/usr/local/apache2/bin/apxs
# rm /usr/local/lib/libsvn*
# make clean && make && make install
此时会自动在/usr/local/apache2/conf/httpd.conf添加
LoadMole dav_svn_mole moles/mod_dav_svn.so
安装完成后,运行svnserver --version确认版本号1.2.3。
SVN服务器安装结束.
第二步，创建仓库 svnadmin create /home/svnrepo
/root/svnrepo为所创建仓库的路径，理论上可以是任何目录
第三步，修改配置文件/home/svnrepo/conf/svnserve.conf
代码
#去掉#[general]前面的#号
[general]
#匿名访问的权限，可以是read,write,none,默认为read
anon-access = none
#认证用户的权限，可以是read,write,none,默认为write
auth-access = write
#密码数据库的路径，去掉前面的#
password-db = passwd
注意：所有的行都必须顶格，否则报错。
建议：为了防止不必要的错误，建议你直接用我上面的内容覆盖掉文件原来的内容
第四步，修改配置文件passwd。
代码
[users]
sxy = sxy
注意
1. 一定要去掉[users]前面的#,否则svn只能以匿名用户登录，客户端不会出现登录窗口，除非你的anon不为none,否则将返回一个错误。
2. 这里的密码都是没有加密的，我按照一些教程所说的用htpasswd生成的密码无法使用。
第五步，启动svn服务
对于单个代码仓库
启动命令 svnserve -d -r /home/svnrepo --listen-host 192.168.100.200
其中-d表示在后台运行，-r指定服务器的根目录，这样访问服务器时就可以直接用svn://服务器ip来访问了。如果服务器有多ip的话--listen-host来指定监听的ip地址.
我们可以在svn客户端中通过svn://192.168.100.200来访问svn服务器
对于多个代码仓库,我们在启动时也可以用-r选项来指定服务器根目录,但访问时需要写上每个仓库相对于svn根目录的相对路径.
比如,我们有两个代码仓库/home/repoa和/home/repob,我们用svnserve -d -r /home --listen-host 192.168.100.200来启动,那么在客户端访问时可以用svn://192.168.100.200/repoa和svn://192.168.1.200/repob来分别访问两个项目
启动完成以后,我们可以用ps aux|grep svnserv来查看是否存在svnserve进程.
第六步 开放服务器端口
svn默认端口是3690，你需要在防火墙上开放这个端口。
/sbin/iptables -A INPUT -i eth0 -p tcp --dport 3690 -j ACCEPT
/sbin/service iptables save
你也可以通过svnserve的--listen-port选项来指定一个已经开放的其他端口,不过这样的话客户端使用也必须家上端口,如svn://192.168.100.200:9999/.
第七步，使用svn客户端导入项目
推荐使用客户端 http://tortoisesvn.tigris.org/
eclipse插件 http://subclipse.tigris.org/
附：svnserve [选项]
有效选项：
-d [--daemon] : 后台模式
--listen-port arg : 监听端口（后台模式）
--listen-host arg : 监听主机名或IP地址（后台模式）
--foreground : 在前台运行（调试时有用）
-h [--help] : 显示这个帮助
--version : 显示版本信息
-i [--inetd] : inetd 模式
-r [--root] arg : 服务根目录
-R [--read-only] : 不赞成；使用档案库配置文件
-t [--tunnel] : 隧道模式
--tunnel-user arg : 隧道用户名（模式是当前用户UID的名字）
-T [--threads] : 使用线程代替进程
-X [--listen-once] : 监听一次（调试时有用）
安装客户机端
window客户机：
直接安装TortoiseSVN-1.1.1-UNICODE_svn-1.1.1.msi，方法同一般软件安装相同。
Linux客户机：
方法舆安装服务器相同。
(注意redhat 9默认安装的SVN版本为0.17.1,它的客户端命令svn无法舆新的SVN服务器通讯,必须重新安装)
我是从“上海全鼎软件学院”毕业的————————
『伍』 什么叫版本控制工具
现在的软件项目开发中，必然涉及版本控制（Revision Control）工具。没有使用版本控制工具的开发工作，有人形容就如同生活在“黑暗时代”。版本控制工具是项目开发中必不可少的，以此进行的版本控制可以确保在软件项目开发中，不同的开发人员所涉及的同一文档都得到更新。
关于软件版本控制
如果在开发团队中没有使用版本控制，多个开发人员共同负责同一个软件文档的开发，每个人在各自的机器上有整个软件文档的备份，并对之实施编程开发，在分别完成各自任务之后，再通过文本比对工具将各自机器上的不同版本的程序整合到一台机器上。没有进行版本控制或者版本控制本身缺乏正确的流程管理，在软件开发过程中将会引入很多问题，如软件代码的一致性、软件内容的冗余、软件过程的事物性、软件开发过程中的并发性、软件源代码的安全性，以及软件的整合等问题。
版本控制的目的是实现开发团队并行开发、提高开发效率的基础。其目的在于对软件开发进程中文件或目录的发展过程提供有效的追踪手段，保证在需要时可回到旧的版本，避免文件的丢失、修改的丢失和相互覆盖，通过对版本库的访问控制避免未经授权的访问和修改，达到有效保护企业软件资产和知识产权的目的。
版本控制的功能在于跟踪记录整个软件的开发过程，包括软件本身和相关文档，以便对不同阶段的软件及相关文档进行表示并进行差别分析，对软件代码进行可撤消的修改，便于汇总不同开发人员所做的修改，辅助协调和管理软件开发团队。
Linux下的版本控制
版本控制在空间上可以保证完成集中统一管理，解决一致性和冗余问题。在开发工作中，开发人员在提交软件代码的时候一般采用服务器/客户端方式，尽管开发人员可以在自己的本地留有备份，但最终唯一有效的只有服务器端的程序代码；在时间上全程跟踪记录工具将会自动记录开发过程中的每个更改细节，和不同时期的不同版本。这在一定程度上可以解决冗余、事务性处理并发性问题。项目管理人员可以通过版本控制对团队中的不同人员，实施操作权限的控制。对于不同角色的开发人员，对软件的不同部分可以定义不同的访问权限。这在一定程度可以解决软件安全性问题。版本控制工具的使用，可以减轻开发人员的负担，节省时间，同时降低人为错误。
『陆』 代码版本控制软件有哪些
2、常用的版本控制软件
Perforce，StarTeam）
--------〉入门级
1.Clear case --------〉中坚级 2.CVS --------〉开源奇葩 3.Visual SourceSafe
--------〉新秀级
4.PVCS --------〉小工作组级 5 Perforce --------〉 6.CCC --------〉元老级 7.StarTeam --------〉 8.RCS --------〉元老级 9.SCCS --------〉元老级 10．Hansky Firefly 11.Others（还有一些比较少见或某个公司专用的软件，如Seapine，北大青鸟的JBCM等）
『柒』 软件架构选择及代码版本管理问题
对于版本控制，主要是你业务覆盖。这个之前做过版本统一和 多版本落地，主要注意的是两部分，一是抽象提取管控新定制需求，二是在已完成业务部分实现业务解耦。
这两步就是实现你第三问的内容。需要你在业务方向上做一个规划，至少是1年周期，想让自己的产品大致覆盖到什么程度，在方向上有一个规划。比如你做的crm，是否有客服业务、用户激活流程粒度、权限划分、是否有营销等，这些都尽可能抽取出 业务流程 ，为以后的定制，有一个定位，这种svn可以规划在不同业务包开分支，这种分支看用户需求采用 。
功能模块解耦后，定制如何实现可配置，就可以并行的去重构。
所有的问题，最终还是在产品 的卖点 。做到普及定制，才是王道。
『捌』 coding 版本控制类型什么意思
一、概述
二、Git基本概念
1、有关存储的四个概念
2、分支（branch）
三、项目管理实战操作
1、安装 GHfW（GitHub for Windows）
2、在Coding上新建一个项目（新建远程仓库）
3、创建本地仓库
4、GHfW 的基本使用
配置： win7 + GitHub for Windows
目标读者：不了解Git,没用过GitHub，想使用Coding且不想使用命令行的同学。
前言：本文的宗旨是一切从简，只讲一些必须用到的步骤和概念。
一、概述
Coding.net 是一个新近的代码托管平台。类似于总所周知的GitHub。Coding的优点在于：一、中文界面；二、托管私人项目。缺点也有：项目的安全性还未受验证。总之有利有弊。
本文主要介绍如何用GHfW软件外包企业 for Windows）对Coding上的项目进行管理。
二、Git基本概念
在介绍GHfW对Coding项目管理之前，先介绍一下Git的基本概念。Git是一个版本控制系统。简而言之是管理代码用的。
1、有关存储的四个概念
工作目录（working directory）：工作目录就是文件夹项目，它持有实际文件。
暂存区（the staging area）：暂存区就像是一个索引，把项目文件都联系在一起。
本地仓库（local repository）：切实进行提供版本控制的地方。
远程仓库（remote respository）：放在网络上的仓库。
一个项目的纳入版本控制的过程大概就是工作目录->暂存区->本地仓库向上逐级递交的过程。当在项目中添加一个新的文件后，也就是在工作目录中添加了一个文件。此时暂存区并不知道有新的文件，于是把添加新文件的事告诉暂存区，这样新文件就被追踪（be tracked）了，同时这个文件被加入（add）暂存区。如果修改的是已经被追踪的文件，仍然需要在修改后将改动加入（add）暂存区。已经加入暂存区的新文件或者改动，可以提交(commit)到本地仓库，纳入版本控制系统。
当使用多个设备开发一个项目，或者多个人共同开发一个项目，远程仓库就派上用场了。远程仓库无非就是本地仓库的一个克隆（clone）。当本地仓库产生新的提交而产生变化之后，只要与远程仓库进行一下合并操作就可以让他们保持同步。
2、分支（branch）
每次将改动提交到本地仓库，本地仓库并不会保存文件被修改的部分，而是保存一份快照。
此图共有有5个Version,每个Version下有三个快照结点，Version1下方A、B、C均为实线结点，Version2下方A、C结点为实线，B结点为虚线
Git管理提交的方式
上 图的每一列代表一次提交，每个青蓝色的结点代表一个文件快照。假设本地仓库当前在Version1，在对文件A、C做改动之后提交到了本地仓库。那么本地 仓库会分别保存一份A、C的快照为A1、C1，并用一个链表分别指向快照A1、C1与原快照结点B，成为一次新的提交Version2。
分支的概念就是建立在这样的基础上的，分支是指向某次提交的指针。由于每个提交之间用一个链表相连接。因此一个分支就相当于是从某个提交对象往回看的历史。
这是一个有向图，HEAD->*develop->Version2->Version1,master->Version3
在develop分支上进行提交前
上图中的master与develop就是两个分支。每一次提交操作都是以某个分支为基础的,Git为了知道当前在哪个分支上工作，保存一个名为HEAD的指针。可以把HEAD想象为当前分支的别名。（develop前面的星号（*）就是用来区分当前分支与其他分支的。）
这是一个有向图，HEAD->*develop->Version3->Version2->Version1,master->Version3
在develop分支上进行提交后
当有新的提交产生时，HEAD会指向该新提交，也即当前分支指向新的提交。例如上图就是在develop分支上进行了一个次新的提交Version3。
三、项目管理实战操作
1、安装 GHfW（GitHub for Windows）
下载链接：
安装过程一键完成。
2、在Coding上新建一个项目（新建远程仓库）
依次是项目名称、项目描述、是否公开、是否启用README.md，许可证，添加gitignore文件
新建项目页面
README：一般项目中都会添加一个README文件对项目进行概述，以便一目了然地知道这个项目是做什么用的，如何使用等信息。README文件采用markdown语法书写。
开源许可证：定义该项目的传播方式，比如他人是否可以商业化使用该项目，他人是否可以随意传播、发布、更改该项目。
.gitignore文件：该文件可以定义哪些文件不添加到仓库中，比如项目产生的临时文件。
3、创建本地仓库
打开GitHub客户端，打开的时候该客户端会要求输入GitHub的账户和密码，如果没有GitHub账户直接跳过就好了。
在Coding新建的项目页面左上角会有如下链接：远程仓库的链接地址
点中该链接并直接拖放到GitHub客户端窗口。在弹出窗口中设置本地仓库的路径。如此一来远程仓库就克隆到本地仓库了。
4、GHfW 的基本使用
整个界面大概分为 新项目添加、项目列表、当前分支、文件提交、未同步到远程仓库的文件列表、已同步的提交历史、以暂存的文件、同步到远程仓库、设置等九个部分
GHfW界面说明
在工作目录中对文件进行增删改等操作后，在GHfW窗口勾选需要提交的修改。然后对这次提交进行描述后提交。最后再把修改同步到远程仓库。
『玖』 代码版本控制用SVN还是Git好
SVN属于被淘汰的上一代版本管理工具。用SVN，你就属于被淘汰的一类。
GIT牛掰不仅仅是牛掰在离线提交这个方面。事实上本座的团队使用GIT根本没有考虑是否能离线提交，每个开发人员基本上走到哪里都可以有网，离不离线不是关键问题。
GIT牛掰的地方在于对分支管理，子项目依赖，代码冲突管理上比SVN高出不止一个数量级。
举个例子：用一个开源的库，我们需要对开源的库某些部分进行修改，但是又想保证该库紧跟官方发布不过时。用SVN的话，要不一切手动，要不你就把你的修改提交到官方源去（基本上是不可能的）。用GIT，我可以克隆一个repository，新建一条branch保持私有修改，官方库有更新随时pull --rebase。
GIT的commit还可以乱序修改。比如说队里的熊孩子搞砸了，一连几个commit都不能编译。太简单了：用git rebase -i可以把一条branch上的坏commit一个一个剔掉。换了SVN，提交了坏代码的话，天皇老子都没法改。
GIT的高级玩法多了去了。学习曲线比SVN要陡，但是培训下团队完全是值得的。现在业界主流都用GIT，数不清的各种工具和云服务都基于GIT。上Github下个代码，人家很潇洒地一站式git clone，你下个zip再解包不寒碜？
就算你是单干，GIT也比SVN好用的多。用SVN如果不用云服务的话你还得自己架一个SVN服务器，GIT的话直接本地repository。