作为源代码控制的zip文件的参数

Question

可以使用哪些参数来反对使用源代码的zip文件作为版本控制的形式？

通常,每个开发人员都在开发自己的程序,并对其负责.但是,有时候其他开发人员参与该计划的工作.

每个开发人员都有自己的zip文件命名约定,包括附加日期,程序名后面的数字,甚至附加_old/_oldold _newversion等......当有一些代码开发合作时.必须检查谁拥有代码的"最新"版本 - 以及它所在的位置,通常会识别出正确的版本.

没有简单的现有方法来对源树进行差异化,并且在开发过程中不需要的更改偶尔会进入代码.

对应于已发布到制造的软件版本的zip文件已存档.这至少增加了一些可追溯性.

此外,在RTM之前,代码将根据先前发布的版本进行同行评审,因此确实存在质量保证.

是否有正式的白皮书解释源代码控制的优势,明确上述内容并非完全有效的源代码控制形式？这里存在的论点是,由于最终产品(制造版本)受到控制,因此审查这些过程没有问题.开发人员以这种方式处理zip文件没有太多问题,但可能没有意识到这些优点.

Answer 1

最好的论据当然是使用像Subversion或Mercurial这样的版本控制系统比使用zip文件搞乱更容易,更安全.我怀疑在这个问题上有很多论文写作,因为为此目的使用zip文件显然是错误的.

关于版本控制的一般优点,有许多SO问题.例如,我如何说服我的部门实施版本控制系统？和/sf/ask/17568911/

Answer 2

• 创建和管理zip文件容易出错.
• 真正的源代码控制为您提供了解代码的工具:
  • 历史浏览
  • 修订版之间的差异
  • 用于跟踪更改源的源文件的注释
• 真正的源代码控制并不困难,那里有很多帮助.

Answer 3

我假设您目前在一家实行这种拉链控制方法的公司工作,而您正在寻找弹药来帮助您改变这种做法.StackOverflow上有很多关于源代码控制的问题,这里的社区对正确的源代码控制的好处和没有它的工作的恐惧几乎完全达成共识(非常好的理由).

我会在这里添加一些东西以使你的战斗受益: 你的公司是@ $#%&$#@ CRAZY!ZIP文件??? 是你@#$#@%KIDDING ME ???

Answer 4

我假设这个问题被问到,因为原始海报在办公室工作,标准做法是共享zip文件.

由于Ned Batchelder给出的理由,Zip文件显然很糟糕.我建议的最大原因是它很笨重,很难合并更改,或者很容易在过去的版本之间找到差异.

我建议您阅读版本控制的可视指南,以获得有关版本控制系统非常有用的原因以及管理代码的优秀方法.

Answer 5

我怀疑将会有多少白皮书将zip文件与正确的源代码控制进行比较,因为有些白皮书会将一个人的生殖器与生锈的黄油刀进行比较并购买一只小狗.

Answer 6

Zip文件作为版本控制的一种非常基本的形式.这是分离源的"状态"的一种方式.但是,它不是一种好的版本控制形式,因为您必须执行大量工作才能执行基本的源代码管理任务.例如:

1. Bob的团队正致力于一项需要更改数十个文件的主要功能.他在自己的私人拉链控制区工作了一段时间.他创建了30个新文件,为12个现有文件添加了功能,并在4个月内对3个现有文件中的现有行为进行了更改.你如何将Bob的工作与过去4个月内演变的主干合并？你手工分散成千上万行代码并决定如何合并它们吗？你如何确保使用15个现有文件的任何内容都没有被破坏？您如何确保不会意外省略Bob的功能或主干功能？
2. Alice正在调查她的代码中的一个错误,并意识到Sam的一个类已经改变了它的行为.萨姆说他没有做出改变.Alice如何找到更改的时间和原因？爱丽丝如何知道谁依赖于变化？
3. 一位主要客户报告了旧版程序中的错误.这个客户需要修复,并且足够重要以保证补丁.如何以旧文件中也存在的方式将代码添加到旧zip文件中？另外,您如何记录这两个变化之间存在关系？

这些只是版本控制系统处理良好的三种情况.情况1由开发分支处理.几乎每个版本控制系统都有一个分支概念,可以并行开发并根据需要合并.任何具有"责备"功能的源控制系统都可以轻松解决情况2,只需搜索提交日志就不易解决问题.情境3是情况1的变体,但是当您合并分支时,大多数版本控制系统都会记录.例如,你要从旧版本中删除分支,修复bug,然后将该分支合并到新代码中.现在有人问"这种变化来自哪里？" 他们看到它是从补丁分支合并而且更改是为了修复错误.

顺便说一句,我已经处于这3种情况中的每一种情况并同时使用SVN和Perforce; 两者都很容易找到解决方案.

Answer 7

这些人已经知道了SCM的所有论据,没有人能够对他们说出来将其出售.这些事情必须发生:

1. 您在本地计算机上安装SCM并使用它.如果必须,让它在每次构建时自动生成这些.zip文件,这样你的多维数据集之外的任何人都不会知道它们之间的区别.

2. 发生了某种灾难,例如失去工作,重新引入了show-stopper bug或者其他一些最糟糕的情况,这是我们都使用SCM的真正原因(我们后来学会欣赏的其他功能).

3. 您不会受到灾难的影响,并且/或者使用您在SCM中的代码的个人副本来解决问题/恢复丢失的工作/无论如何.

4. 你是英雄,每个人都想知道你是怎么做到的.

只有亲身体验由不良SCM实践造成的损失的痛苦,您的组织才能认识到SCM的好处.你足够聪明,可以从别人的错误中吸取教训,但不是每个人都有.剩下的时间里,你只比团队的其他成员高出2/3倍,也许,也许他们会想知道如何.

顺便说一句,这就是你如何在组织中获得敏捷,持续集成,单元​​测试等等:以身作则.