Questions tagged «svn»

我试图了解分布式版本控制系统（DVCS）的好处。 我发现颠覆再教育和本文由马丁·福勒是非常有用的。 Mercurial和其他DVCS促进了使用变更集和本地提交的代码处理新方法。它防止合并地狱和其他协作问题 我们不受此影响，因为我练习持续集成，除非在进行实验，否则不能在私有分支中单独工作。我们为每个主要版本使用一个分支，其中修复了从主干合并的错误。 水星让你有中尉 我知道这对于像Linux这样的大型项目很有用，但是我看不到小型且高度协作的团队（5至7人）的价值。 Mercurial更快，占用磁盘空间更少，完整的本地副本允许更快的日志和差异操作。 我也不对此感到担心，因为即使我正在处理非常大的项目，我也没有注意到SVN的速度或空间问题。 我正在寻找您的个人经验和/或前SVN怪才的意见。特别是关于变更集的概念和整体性能的提高。 更新（1月12日）：我坚信值得尝试。 更新（6月12日）：我亲吻了Mercurial，我很喜欢。他的樱桃当地风味的味道。我亲吻Mercurial只是为了尝试。我希望我的SVN服务器不要介意。感觉很不对劲。感觉很好。并不是说我今晚恋爱了。 最终更新（7月29日）：我荣幸地复习了Eric Sink的下一本书，名为“ 版本控制示例”。他说服了我。我去Mercurial。

300 version-control  git  mercurial  dvcs  svn 

我的组织正在考虑从SVN迁移到Git。反对搬迁的一种论据如下： 我们如何进行版本控制？ 我们有一个基于NetBeans平台的SDK发行版。由于SVN修订版是简单的数字，因此我们可以使用它们来扩展我们的插件和SDK构建的版本号。转移到Git时如何处理？ 可能的解决方案： 使用Hudson的内部版本号（问题：您必须检查Hudson才能将其与实际的Git版本相关联） 手动升级版本以保持夜间稳定（问题：学习曲线，人为错误） 如果其他人遇到了类似的问题并解决了该问题，我们将很乐意听听如何解决。

131 version-control  git  svn  builds  versioning 

我在政府机构工作。这里使用的技术和开发软件的方法已经过时了。 它们具有大量的存储空间，但没有合适的空间来保留和维护用于自动化此处大部分工作的应用程序。 该机构不允许我使用SCM软件（例如GIT或SVN）。 保持代码质量并稍后能够在应用程序中添加新功能的最佳方法是什么？ 如何记起对代码所做的更改而又不破坏代码？ 编辑：我忘了提及，它们为每台计算机都有网络驱动器，并且这些网络驱动器会以某种方式定期进行备份或保存备份。但是，如果我不创建自己的计划以保存工作并能够在不破坏现有代码的情况下添加新功能，那么与SCM解决方案相比就没有太大的优势。 编辑：由于许多人建议使用便携式Git，所以我必须添加更多信息。我尝试安装Visual SVN服务器，但失败了，因为我没有安装管理员权限。我也尝试下载常规的Git Shell，但是防火墙或网络设置不允许我访问Git下载页面。我什至尝试过，将便携式Git发送到我的Gmail电子邮件中。Google检测到了软件包中的exe文件，也不允许我在工作计算机上下载可移植的Git版本。我还要提到的另一件事是，应用于机构内部计算机的网络策略不允许使用USB存储设备。您可以使用USB端口为智能手机充电或为小扬声器等小工具供电。也有人说过，有些计算机甚至不允许上网。

110 git  code-quality  svn  scm 

我知道并使用两个版本控制系统：Subversion和git。到目前为止，Subversion被用于我是唯一开发人员的个人项目，而git被用于开源项目和我相信其他人也可以在该项目上工作的项目。这主要是因为git惊人的分叉和合并功能，每个人都可以在自己的分支上工作。非常便利。 现在，我将Subversion用于个人项目，因为我认为git在这里毫无意义。这似乎有点过大。如果我是唯一的开发人员，则将其集中（通常在我的家庭服务器上）对我来说是可以的；我还是要定期备份。我不需要建立自己的分支的能力，主要分支是我的分支。是的，SVN对分支有简单的支持，但是我认为对它的更强大的支持是没有意义的。合并可能会很痛苦，或者至少从我的小经验来看。 我是否有充分的理由在个人项目上使用git？

84 tools  version-control  git  svn 

我正在写一篇文章，希望有一些经验证据，也许是纵向数据，可以对这些技术的流行程度进行比较。 是否有任何统计数据表明Git与SVN相比受欢迎？

78 git  svn 

我想知道我处理需要从版本控制中删除的源文件的方式是否被视为不良做法。 我想根据该示例向您解释： 最近我非常生气，因为我必须在程序中将Java类繁琐地整理出来，这些类基本上是无效的代码，但是在这些Java类中都没有文档记录和注释。当然，需要删除它们，但是在删除这些多余的东西之前，我有一个-有些人可能说奇怪-习惯： 我不会立即通过SVN-> Delete（用您选择的版本控制系统的delete命令替换）来删除这些冗余文件，而是将注释放置在这些文件中（这些文件的开头和结尾处都是引用）被删除+我的名字+日期，以及-更重要的是- 为什么被删除（在我的情况下，因为它们已经死了，代码令人困惑）。然后保存并提交给版本控制。下次当我必须在项目中提交/签入版本控制时，我按SVN-> Delete，然后最终将它们在版本控制中删除-当然仍然可以通过修订来恢复，这就是为什么我采用了这种习惯。 为什么要这样做而不是立即删除它们？ 我的理由是，我至少要在存在那些冗余文件的上一个修订版本中要有显式标记，为什么应该删除它们。如果我立即删除它们，它们将被删除，但是没有地方记录为什么删除它们。我想避免这样的典型情况： “嗯...为什么删除了那些文件？我以前工作得很好。” （按“还原”->还原然后再消失的家伙将在下个星期永远消失或不可用，下一位受让人必须像我一样单调乏味地找出这些文件的内容） 但是您没有注意到为什么这些文件在提交消息中被删除了吗？ 我当然可以，但是同事有时看不到提交消息。在您试图理解（在我的情况下为死机）代码时，首先使用所有关联的提交消息检查版本控制日志的情况并不常见。与其查看日志，不如立即看到该文件无用。这样可以节省她/他的时间，并且她/他知道此文件可能已恢复为坏文件（或至少引起了一个问题。）

53 version-control  svn  evidence-based 

我在一个CVS疯狂和Bugzilla坚果的地方工作。 每个发行版都有太多分支，以至于无法计数。每个人都在不断地自动合并。 这项工作没有流动性。一切都感觉锁步。即使是简单的事情，也需要25个步骤。这不像是在工厂生产线上，而是每天自己建立工厂。 情况示例： 要修复一个错误，首先我要获得一个干净的新虚拟机。然后，根据Bugzilla报告中描述的另一个分支，为该单个错误修复程序创建一个分支。我将分支安装在计算机上，进行设置。我修复了错误。我将其检入，将其和机器留给其他人进行测试。然后，我必须进入错误控制软件，并解释我的工作并编写测试用例以及所有步骤。最终，其他人将其与发行版合并。 无论错误有多微小，我都必须做所有这些事情。有时人们将多个错误的工作结合在一起，但是正如我所说的那样，分支太多了，这几乎是不可能的。 在其他任何工作中，我只想修复该错误即可。我什至不记得使用SCM，尽管我曾经做过的每一项工作都使用过SCM：这是因为在其他每项工作中，他们都以某种方式使其无法使用。 在这个过程中是否有障碍，并成为自身的终结？这甚至是工程吗？

50 issue-tracking  workflows  svn 

程序员之所以喜欢SVN而不是CVS的原因之一是前者允许原子提交？这是什么意思 ？

34 svn  versioning  cvs 

假设有一个由十个敏捷开发人员组成的团队。每天他们每个人都从董事会中挑选一项任务，并对它做出一些更改，直到（直到一天结束）他们已经完成了任务。所有开发人员都直接通过主干签入（Google风格，每次提交都是候选版本，使用功能切换等）。 如果他们使用的是像SVN这样的集中式CVS，那么每当其中一个提交时，构建服务器就会针对其他9个开发人员的工作进行集成并测试其更改。构建服务器几乎将全天连续运行。 但是，如果他们使用的是git之类的DCVS，则开发人员可能会等到完成任务后，再将所有本地提交一起推送到中央存储库。直到一天结束，他们的更改才会被整合。 在这种情况下，SVN团队更加频繁地进行集成，并且比git团队更快地发现集成问题。 这是否意味着DVCS比老式的集中式工具更不适合连续团队使用？你们如何解决这个推迟推送的问题？

34 git  svn  continuous-integration  dvcs  branching 

我在一个部门中工作，以前没有人使用过源代码管理，包括我自己。 我正在努力推动这一概念。我花了一些时间研究SVN。我学了一些基础知识。我可以使用命令行或Tortoise创建/更新/签出/提交。我开始学习如何标记和分支，但是仍然对分支和主干之间的冲突感到困惑。我仍在学习，但是我没有一个能向我展示任何东西的自然人。它全部来自书籍/教程以及反复试验。 根据我在网上阅读的内容，似乎git最好了解一些东西，但是它也更加复杂。我不想让自己不知所措。我应该在转入git之前继续掌握svn还是现在明智地跳到git？ 两种方法都有优点和缺点吗？

31 svn  git 

我怀疑我专注于错误的问题，因此在介绍我设想的可能次优的解决方案之前，我将首先描述我认为问题所在。 当前情况： 目前，我的同事只有在很长一段时间内才提交他们的代码更改，这些更改分散在整个项目中。我猜这是进步，因为不久前他们只是将.zip存档放在某些网络共享上。尽管如此，合并仍然是一场噩梦-坦白地说，我已经受够了。而且我也厌倦了交谈，解释和乞讨。这只是必须停止-不要让我不断成为“坏人”。 我的解决方案： 由于似乎对这些问题一无所知，并且/或者对这些问题没有兴趣，而且我不能指望任何努力可以持续几天以上……因此，我想让几个小时的颠覆服务器来做这些事情。唠叨。 我的问题： 我是在这里偏离基地还是在看错问题？似乎我缺少了一些东西，而且我认为通过查看解决问题的工具来问错了事情。 我应该在寻找一种工具来解决此问题，还是应该采取什么措施解决此问题？

28 version-control  teamwork  svn 

最近，我碰到了一篇有关分支和合并以及SCM的MSDN文章：分支和合并入门-Chris Birmele。 他们在文章中说“大爆炸合并”是一种合并的反模式： 大爆炸合并-将分支合并推迟到开发工作的尽头，并尝试同时合并所有分支。 我意识到这与我公司对所有开发分支的工作非常相似。 我在一家非常小的公司里工作，只有一个人担任最终审查+干线合并授权。我们有5个开发人员（包括我在内），我们每个人都会被分配一个单独的任务/错误/项目，我们每个人都将离开当前主干（subversion），然后在我们的分支中执行开发工作，测试结果，编写文档如有必要，请与其他开发人员进行同行评审和反馈循环，然后将分支提交给我们的项目管理软件进行评审+合并。 我的老板是主干存储库的唯一授权，实际上将把分支的所有审核推迟到一个时间点，在该时间点他将尽其所能进行审核，一些​​分支将被退回以进行增强/修复，有些则被丢弃。分支将直接合并到主干中，由于冲突等原因，一些分支将被退回。 对于我们来说，在最终审阅队列中有10-20个活动分支合并到主干中并不少见。 在最后的审阅和合并阶段，我们经常还必须解决冲突，因为两个分支是在同一主干上创建的，但修改了同一段代码。通常，我们可以通过重新分支，重新应用更改并解决冲突，然后提交新分支进行审核（可怜的人变基）来避免这种情况。 我有一些直接的问题是： 我们是否展示了被称为“大爆炸合并”的非常反模式？ 我们看到的某些问题是此合并过程的结果吗？ 我们如何在不增加我老板的瓶颈的情况下改善这一合并过程？ 编辑：我怀疑我的老板会放松对中继存储库的控制，还是允许其他开发人员合并到中继。不知道他这样做的原因是什么，但是我真的不打算提出这个话题，因为这个话题以前被提出过并且很快就被否决了。我认为他们只是不信任我们，这是没有意义的，因为无论如何都跟踪了一切。 任何其他见解这种情况将不胜感激。

28 svn  anti-patterns  merging  scm 

可能重复： 我是Subversion极客，为什么我应该考虑或不考虑Mercurial或Git或任何其他DVCS？ 有时，您会听到有人说分布式版本控制（Git，HG）本质上比集中版本控制（如SVN）更好，因为在SVN中合并非常困难且痛苦。关键是，我在合并SVN方面从未遇到任何麻烦，并且由于您只听说过DVCS倡导者而非实际SVN用户提出的主张，所以这往往使我想起电视上那些令人讨厌的广告，试图让演员冒充假装您已经拥有并且可以正常工作的东西很难卖给您，从而卖给您不需要的东西。 总是提出的用例是重新合并一个分支，这再次使我想起那些稻草人产品广告；如果您知道自己在做什么，则一开始就不应该（也永远不必）重新合并分支。（当然，当您从根本上做错和愚蠢的事情时，这很难做到！） 因此，撇开荒谬的稻草人用例，SVN合并中有什么比DVCS系统中合并更难？

28 git  svn  mercurial  dvcs  merging 

我搜索了git / mercurial / bazzr系统，使其优于集中式系统（subversion，perforce），但没有找到任何商业原因。 如果您试图将DVCS出售给非技术人员，您会为DVCS 增加利润提供哪些论点。 我将很快向我的经理介绍git，这将需要一些时间来转换出Subversion存储库，并花费一些费用来购买smartgit许可证。 编辑我试图使这个问题成为关于集中式与分散式的一般性讨论，但是不可避免地它变成了git vs subversion。当然，有比颠覆更好的集中式系统。

26 version-control  mercurial  dvcs  svn  git 

我已经看到了很多有关git分支模型的建议，最普遍的观点似乎是直接在master分支上进行更改是一个坏主意。 我们的一位同事很高兴直接在主分支上进行更改，尽管进行了几次交谈，但他们似乎不太可能更改此更改。 在这一点上，我无法说服一个不擅长直接在师傅上工作的同事，但我想了解会与他的工作方式相抵触的事物，知道何时需要重新访问这个问题。

25 version-control  git  svn  branching