可以使用哪些参数来反对使用源代码的zip文件作为版本控制的形式？
一般而言，每个开发人员都在开发自己的程序，并对此负责。但有时候其他开发人员也参与该计划的工作。
每个开发人员都有自己的zip文件命名约定，包括附加日期，程序名后面的数字，甚至附加_old / _oldold _newversion等......当有一些代码开发时有合作。必须检查谁拥有代码的“最新”版本 - 以及它所在的位置，通常会识别出正确的版本。
没有简单的现有方法来对源树进行差异化，在开发过程中，不必要的更改偶尔会进入代码。
与已发布到制造商的软件版本对应的zip文件已存档。这至少增加了一些可追溯性。
此外，在RTM之前，代码会根据之前发布的版本进行同行评审，因此确实存在质量保证。
是否有正式的白皮书解释源代码管理的优势，明确上述内容并非完全有效的源代码控制形式？这里存在的论点是，由于最终产品（制造版本）受到控制，因此审查这些过程没有问题。开发人员以这种方式处理zip文件没有太多问题，但可能没有意识到这些优点。
答案 0 :(得分：15)
最好的论点当然是使用像Subversion或Mercurial这样的版本控制系统比搞乱zip文件更容易，更安全。我怀疑在这个问题上有很多论文写作，作为使用 用于此目的的zip文件显然是错误的。
关于版本控制的一般优势，有许多SO问题。例如How can I convince my department to implement a version control system?和https://stackoverflow.com/questions/250984/do-i-really-need-version-control
答案 1 :(得分：15)
答案 2 :(得分：12)
我假设您目前在一家采用这种拉链控制方法的公司工作，而您正在寻找弹药来帮助您改变这种做法。 StackOverflow上有很多关于源代码控制的问题，这里的社区对正确的源代码控制的好处和没有它的工作的恐惧几乎完全达成共识（非常好的理由）。
我会在这里添加一些东西以使你的战斗受益：你的公司是@ $＃％＆amp; $＃@ CRAZY !!! ZIP文件???是你@＃$＃@％KIDDING ME ???
答案 3 :(得分：6)
我假设这个问题被问到，因为原始海报在办公室工作，标准做法是共享zip文件。
由于Ned Batchelder给出的理由，Zip文件显然很糟糕。我建议的最大原因是它很笨拙，很难合并更改，或者很容易在过去的版本之间产生差异。
我建议你阅读A Visual Guide to Version Control，了解一些关于版本控制系统非常有用的好论点，以及管理代码的优秀方法。
答案 4 :(得分：6)
我怀疑将会有很多白皮书将zip文件与适当的源代码控制进行比较，因为会有白皮书将生理黄油刀切成一条生肖黄油刀并购买一只小狗。
答案 5 :(得分：6)
Zip文件是一种非常基本的版本控制形式。这是分离源的“状态”的一种方式。但是，它不是良好的形式的版本控制，因为您必须执行大量工作来执行基本的源代码管理任务。例如：
这些只是版本控制系统处理得很好的三种情况。情况1由开发分支处理。几乎每个版本控制系统都有一个分支概念，可以并行开发并根据需要合并。任何具有“责备”功能的源控制系统都可以轻松解决情况2，只需搜索提交日志就不易解决问题。情境3是情况1的变体，但是当您合并分支时，大多数版本控制系统都会记录。例如，你要从旧版本中删除分支，修复bug，然后将该分支合并到新代码中。现在有人问“这种变化来自哪里？”他们看到它已经从补丁分支合并，并且进行了更改以修复错误。
顺便说一句，我已经处于这3种情况中的每一种情况并同时使用SVN和Perforce;两者都很容易找到解决方案。
答案 6 :(得分：5)
这些人已经知道了SCM的所有论据，没有人能够对他们说出将其出售的内容。这些事情必须发生：
您在本地计算机上安装SCM并使用它。如果必须的话，让它在每次构建时自动生成这些.zip文件，这样你的多维数据集之外的任何人都不会知道它们之间的区别。
发生某种灾难，如失去工作，重新引入停止错误或其他一些最糟糕的情况，这是我们都使用SCM的真正原因（我们后来学会欣赏的其他功能） ）。
您不受灾难的影响，并且/或者使用您在SCM中的代码的个人副本来解决问题/恢复丢失的工作/无论如何。
你是英雄，每个人都想知道你是怎么做到的。
只有亲身体验由不良SCM实践造成的损失的痛苦，您的组织才能意识到SCM的好处。你足够聪明，可以从别人的错误中吸取教训，但不是每个人都有。剩下的时间里，你只比团队的其他成员高出2/3倍，也许，也许他们会想知道如何。
顺便说一句，这就是你如何在组织中实现敏捷，持续集成，单元测试等：以身作则。
答案 7 :(得分：4)
ZIP解决方案需要在开发周期结束时采取主动步骤，因为当开发周期中没有人注意到它们没有发生时，事情往往会被删除。有点像最后的代码清理，当事情变慢时，你总是计划这样做。
集成到开发环境中的SCM几乎强制/鼓励在整个过程中通过少量工作来保留版本历史记录。这使得更有可能实际创建版本历史记录。
使用ZIP作为SCM
我不打算像ZIP文件解决方案中的其他一些一样努力。它至少比没有好。它是保存版本历史记录的一种非常有效的方法，它只是更加劳动密集，容易出错，并且缺乏许多有用的功能。
了解您的销售人员
开发小组中的某个人：将您的论点集中在诸如使用更改历史记录轻松进行故障排除，安全性以尝试重大代码更改（因为回滚）以及避免工作被覆盖的事故等方面。其他开发者。
非技术经理/ Bean计数器：有免费/低成本的工具可以降低版本控制的人工成本，并为每个开发人员正在做的事情提供更大的责任/透明度编码mostakes的来源。
答案 8 :(得分：2)
我很久以前为一家为DVD影片创作的公司编写了一个版本控制工具。在此之前他们什么都没有，只是一个充满剪辑，图标，脚本等的目录，任何人都可以躲开，如果出现问题就无法回溯等等。但是这些人是“艺术家”，而不是程序员，所以他们可以不是（不会???）训练使用一个体面的版本控制系统。因此，作为一个极小的，脱离泥泞的级别工具，我编写了一个实用程序，它压缩了目录的当前状态，为Zip提供了一个有意义的名称（日期+用户提供的评论）并将其粘贴在备份目录，还允许您还原其中一个备份。
所以拉链可以提供最低级别的版本控制，而且我说的是在适合技能级别时认可该方法的人（在编程方面，我不想暗示他们无法操纵像素！）使用它的人。
但作为一名程序员，你应该考虑使用一种真正帮助你的工具。因此，您希望能够比较单个文件的差异，比较完整里程碑集之间的差异，并且（如果您正在处理除了普通程序之外的任何事情）处理分支和合并。如果你想要这些功能，你需要比zip文件更好的东西。
我曾经使用过ComponentSoftware RCS，如果它不是因为它在WAN上的性能不佳，我们可能仍在使用它：它很便宜（即使是单一开发人员使用也是免费的，我过去使用它的形式在家里）和简单易用。但是现在我建议看看SubVersion。它非常灵活，理解起来相当简单，有一套很好的Windows工具可以让它更容易（例如Tortoise，Ankh），而且......最重要的是......你可以免费运行它。
答案 9 :(得分：1)
这不好，因为在发布之前只创建一个zip就意味着失去了版本控制所带来的大量功能。
有时您应该在添加/删除/更改功能aspekt后登记到存储库。因此，您可以稍后在发生错误时返回，因为您认为migth是由于此更改。或者当你说“在三月份的某一天文件格式发生变化之前，这种方法有效”。更改后的命名修订使其更容易记住，因为您忘记了2009年3月27日所做的事情。
答案 10 :(得分：1)
一般来说，每个开发人员都在工作 在他们自己的计划和有一个 对此负责。但是这里有 当然是其他开发者的时候 参与该计划的工作。
在正常的开发商店，这根本不是真的。不同的人一直在使用相同的源代码。 XP几乎是强制性的。即使您将代码分成模块，仍然会有与至少两个程序员有关的代码的交互点。
当然，如果不使用源代码控制，几乎不可能在没有重大问题的情况下进行协作。但是你描述的场景更适合于适应这种限制而不是理智的项目结构。
只有一个人在模块上工作意味着当那个人休假时你什么也不会发生，当他离开公司，长时间生病或死亡时你会遇到重大问题。
答案 11 :(得分：1)
你如何合并？你怎么做注释？你怎么平分？存储更改日志的位置？只需转到维基百科并查找“版本控制”并在列表中找到：zip文件可以在整个页面中做两件事。
这就像问“什么论据可以用来作为复式记账的形式？”。这是完全不同的事情。
答案 12 :(得分：1)
对于争论，有Walter Tichy的original paper on RCS。
对于缺少的功能，在许多其他功能中，可以合并来自不同版本的更改。 git和darcs之类的工具特别好地支持了这一点，并且在较小程度上也是很好的。
P.S。对Mercurial粉丝来说：问题在于Mercurial将合并过程委托给外部工具，并且对于那些善变的新手来说，知道使用哪种工具或理解它们如何工作是非常困难的 - 合并的多变模型似乎比其他工具更强大但相应地难以掌握。
答案 13 :(得分：1)
我还没有看到答案包括Eric Sink的Source Control HOWTO，但这是一个有价值的参考。我还没有看到任何关于版本控制的正式白皮书，但我不确定关于“有效性”的论点是你最强的。您在问题中描述的问题表明当前方法存在一些非常严重的缺陷。如果你的环境中的“权力”不能被说服，那就完全改变论点。
如果你把它作为一个质量控制的问题，并指出持续集成作为鼓励它的实践，那么zip文件的版本控制方法不是“不完全有效的版本控制形式”，而是一个障碍实施持续整合作为一种实践。
您的问题并未表明“受控制”的最终产品是否以任何自动方式进行测试（除了经过审核外）。如果您描述的过程也会阻止这种情况发生，那么肯定也会将其添加到您的论点中。
答案 14 :(得分：0)
我认为你最好的论点是展示一种良好的源代码控制形式，并展示它是多么强大。不要捣毁目前正在做的事情（因为某人肯定会情绪化地依附于此）。您不想废弃“ZIP源控制方法”。展示SVN之类的力量。让它很容易解释。显示常见用例。 （一个可靠的演示会有所帮助。）
让源代码控制版本自行销售。