Questions tagged «svn»

SVN是“ Subversion”的缩写，是一个开源版本控制系统

5
奇怪的公司发布周期：进行分布式源代码控制吗？
抱歉，这篇文章很长，但我认为值得。 我刚从一家小型.NET商店开始，其运作方式与我工作过的其他地方有很大不同。与我以前任职的职位不同，此处编写的软件针对多个客户，并且并非每个客户都同时获得最新版本的软件。因此，没有“当前生产版本”。当客户确实获得更新时，他们还将获得自上次更新以来可能已添加到软件中的所有功能，而这可能是很久以前的事了。该软件是高度可配置的，并且可以打开和关闭功能：所谓的“功能切换”。此处的发布周期非常紧张，实际上它们没有按计划进行：功能完成后，软件便部署到了相关客户。 该团队仅在去年从Visual Source Safe迁移到Team Foundation Server。问题是他们仍然像使用VSS一样继续使用TFS，并在单个代码分支上强制执行Checkout锁定。每当将错误修复发布到现场时（甚至对于单个客户），他们都只需构建TFS中的内容，测试该错误是否已修复并部署给客户！（我自己来自制药和医疗设备软件背景，这真是难以置信！）。结果是半熟的开发人员代码甚至未经测试就投入生产。Bug总是会渗入发行版中，但是如果刚获得构建的客户通常不使用该bug所在的功能，他们将不会看到这些bug。主管知道这是一个问题，因为该公司正在逐渐发展壮大突然之间有一些大客户加入，而一些小客户也加入了。 有人要求我查看源代码控制选项，以消除错误的代码或未完成的代码的部署，但又不牺牲团队发行版的某种异步特性。在我的职业生涯中，我曾使用过VSS，TFS，SVN和Bazaar，但是TFS是我大部分经验的去处。 以前与我合作的大多数团队都使用Dev-Test-Prod的两个或三个分支解决方案，其中一个月的开发人员直接在Dev中工作，然后将更改合并到Test然后是Prod，或者在“完成时”升级，而不是在一个固定的周期。使用定速巡航或团队构建的自动化构建。在我之前的工作中，Bazaar被使用在SVN之上：开发人员在自己的小型功能分支中工作，然后将其更改推送到SVN（与TeamCity绑定）。很好，因为很容易隔离更改并与其他人的分支机构共享。 在这两种模型中，都有一个中央的dev和prod（有时是测试）分支，通过该分支推送了代码（标签被用来标记生产该版本的prod中的构建...这些都被制成了分支以修复错误。发布并合并回开发人员）。但是，这确实不适合此处的工作方式：没有命令何时发布各种功能，何时完成将它们推入。 有了这个要求，我看到的“持续集成”方法就失效了。为了获得与持续集成的新功能，必须通过dev-test-prod来推送它，这将捕获开发中所有未完成的工作。 我认为，要解决此问题，我们应该使用没有开发测试prod分支的大量功能分支模型，而是将源作为一系列功能分支存在，当开发工作完成时，这些功能分支将被锁定，测试，固定，锁定，经过测试然后发布。其他功能分支可以在需要/想要时从其他分支获取更改，因此最终所有更改都会被其他人吸收。这完全符合我上一份工作所经历的纯粹的Bazaar模型。 听起来如此灵活，但似乎没有某个开发主干或prod分支似乎很奇怪，我担心分支无法进行重新集成，或者后期的微小更改永远不会被其他分支和开发人员所抱怨。合并灾难... 人们对此有何想法？ 第二个最后一个问题：我对分布式源代码控制的确切定义有些困惑：有些人似乎暗示它只是没有像TFS或SVN这样的中央存储库，有人说这是关于断开连接的（SVN断开了90％并且TFS具有功能完善的离线模式），其他人则说这与功能分支和分支之间没有父子关系的合并的简便性有关（TFS也具有无基础的合并！）。也许这是第二个问题！
2
如何在GitHub上控制项目的版本
如今，我试图在GitHub上花费尽可能多的时间（即使我是团队中唯一的团队成员），以真正感受到现实世界中企业应用程序的情况。 我要解决的一个问题是控制版本。假设我们开始了一个项目。然后，团队成员创建了一些分支并在那里发展。准备好进行生产时，我们将所有分支与master分支合并。最后，我们开始使用version 1.0。 现在该版本1.0已发布，并且该软件的该版本存在一些问题。我们希望开始开发版本1.1，以解决由于匆忙执行项目而引入的问题。 现在，问题是这样的： 我们应该如何在这里控制版本控制？ 我们是否应该为此创建一个新分支，v1.0并在其中保留1.0软件的版本，并在某些分支上（或不进行）开发，与之合并master，一起使用version 1.1？ 是否有针对此类情况的约定？
6
SVN使用不佳-Mercurial是答案吗？
在工作中，我们使用SVN，但仅是名称。我们不分支或合并。我们保留该存储库的两个副本，其中一个充当“标签”分支，在进行部署时会被复制，并保留用于错误修复和立即“必须尽快上线”的功能。我们必须记住将一个副本中所做的更改复制到另一副本（“主干”）中。我们在存储库中的一个文件夹中有十二个项目，而不是将它们分开。简而言之，我们使用SVN的唯一目的就是能够提交。其他所有操作都是手动完成的。 我一直在评估Mercurial；我过去曾经使用过Git（我是团队中唯一使用过DVCS的人），而且我正在迅速接手Mercurial。我正在讨论将Mercurial作为一种“更好的做事方式”介绍给团队的其他成员，因为分支很容易，合并更容易，而且我们可以将内容本地化为我们的核心内容，而只将它们推送到中心准备好后分支。我们将获得SVN的所有好处（而且由于没有人真正了解SVN，我们现在并没有得到太多好处），而且对于新功能，我们不必拥有大量未版本化的文件，因此，如果我们必须回滚我们搞砸了。工作流程似乎更简单-我们只需要记住“ Commit”是本地的，“ Push”就像SVN的提交， 这是一个好方法吗？请记住，团队非常灵活，将与一切能够改善我们的工作质量并使我们的工作变得更轻松的事情一起工作-CIO甚至问我，当我提到我们不充分利用SVN的潜力时，有更好的东西可以使用吗？” 所以他也同意。
3
计算错误代码的成本
我正在寻找能说服管理层投入精力进行重构的论点。 我们使用Jira记录工作，并将每个svn-commit与jira调用相关联。 我的想法是执行以下操作： 手动发现极难实现但经常使用的代码区域：来自User-POV和Developer-POV的区域（错误修复） 获得包含JIRA问题的svn-commits 根据某些条件（问题类型，版本，优先级等）过滤问题 计算在这些错误上花费的时间/精力 估计工作量和重构风险 出示这些数字并寻求解决方法。 你觉得这怎么样？这样的测量是否有用和/或令人信服？优缺点都有什么？
2
工作流程，编辑当前任务中没有的内容
通常，当我编程时，我要完成一个明确的任务，但是会发现我想继续进行的烦人的事情要清理。 在这里，我看到三个选项： 以后再做（可能会忘记/不得不花费时间添加票证） 现在就做，并将其与我当前的工作一起提交（不清楚） 现在执行并分别提交（必须找到它，可能会犯一个错误，无意中选择了选项2） 这可能是相当基本的，但是有什么方法可以使用svn / git / other来规避呢？
2
当不再存在缺少元数据的情况时，v1.5之前的SVN中的合并带来的不便现在是否已经过时？
我开始使用SVN，因此有很多消息来源说，与DVCS工具相比，SVN中的合并非常困难。在最近的问题，我能找到这里SE是从2012年开始。 有时会提到原因是v1.5之前的SVN没有元数据，但是SVN现在是1.8.9版本。 鉴于SVN现在比v1.5更加成熟，尤其是我们没有使用SVN 1.5，所以我们不会因为提到的元数据不足而受苦- 这些反对SVN的论点是否仍然有足够的有效性？ 我知道DVCS有一种完全不同的方法，通常更可取，但是对于出于某些原因“必须”使用SVN的用户，合并不再是真正的“地狱”，对吗？
4
将Web应用程序直接从SVN部署到生产环境是否可以接受
题 是否有合理的理由不使用SVN进行生产部署，或者这仅仅是个人喜好而没有针对SVN的真实案例？ 背景 我的工作场所具有在SVN中标记发布的文化，然后使用（svn co或svn switch直接包括）将这些发布直接部署到各种Web服务器。 我个人对此有一个问题，因为我相信如果不使用构建和部署脚本，某种形式或自动部署，就会丢失集成环境设置，因为它们没有文档说明。然而，不仅如此，我有一种直觉，认为这样做可能存在隐藏的危险，而这种危险尚未被抬起头来。 我已经向负责将代码部署到我们的各种环境（阶段，预生产，生产）等中的运营人员提出了自己的担忧。他们的观点几乎是到目前为止效果很好，没有理由进行更改。 编辑： 我的意思是关于构建和部署： 例如，如果开发人员需要为特定环境添加web.config设置。Web.config通常不保存在svn中，因此无需任何形式的自动构建脚本即可手动更新这些文件。因此，如果它们丢失或OPS忘记为发行版在web.config中添加字段，则可能会遇到问题。 可以使用XMLPoke自动生成适合于特定环境的web.config的构建脚本非常理想，因为您有一个可版本化的脚本，该脚本记录了每个环境所需的所有更改。 当前的构建和部署方法 对于有问题的项目，开发人员可以手动构建发行版，而其他项目则可以使用NANT或MSBuild将构建步骤自动化。 对于大多数项目，数据库迁移是通过DB脚本，迁移脚本（Migrator.NET）或CMS程序包进行的。 CI通常是由Team City在每次签入的基础上完成的，我们有一个代码审查过程，所有票证都在分支机构中完成，然后在进入中继线之前进行同行审查，以确认其有效性和正确性/质量（运作良好）。 但是，实际的代码部署几乎总是通过SVN来进行，或者是通过签出带标记的版本，或更通常是通过SVN Switch来进行。在我们使用存储库作为部署过程的一部分时，这让我感到奇怪。 配置通常不会经常更改，配置文件中唯一会发生的事情就是特定于环境的信息。其他所有内容都在数据库中。 不要误会我的意思，这行之有效。但是，我想尝试推动自动化的构建和部署。我已经在Rails和Capistrano以及用于Cygwin，Nant和SSH的个人项目中使用了它。 更重要的是，我需要非常具体的有效参数来使我的同事转变为使用自动生成和部署。 还是没有真正的有效论据反对使用SVN专门部署到生产环境？
1
在Subversion中使用Git Flow的障碍
我的工作团队正在使用Subversion作为我们的VCS来启动一个新项目（出于这个问题的考虑，您可以将其视为一成不变的）。我们仍处于该项目的早期阶段，并试图就分支模型达成共识。我们之前的项目基于非标准版本模型，该模型导致管理现有版本的修补程序和修补程序时出现问题。 我发现不同的分支模型相当复杂，但是我确实很清楚地理解的一种模型是git flow。我很好奇在Subversion中实现这种变化会有多么困难/不期望。显然，在分支机构上进行协作的人会有所不同。功能分支必须集中而不是局限于本地存储库，但是据我所知，该模型的其他概念应该可以在Subversion中重现。 这种方法的缺点或挑战是什么？我听说相对于Git，在SVN中“合并成本很高”。但是我尚不清楚这在实践中意味着什么，或者它将如何影响我们使用像分支模型这样的git flow的能力。 这种方法最大的担忧是什么。有没有一种类似的清晰方法在Subversion中更自然？
10 svn  branching  gitflow 
4
在Subversion中，应如何设置应用程序的新主版本？
我即将开始开发我的商业应用程序的新版本（版本4）。我使用Subversion。 根据您的经验，错误和成功，您将如何建议我在Subversion中设置新版本？ 这里是一些信息：在版本4发布之后，我打算在版本3中继续发布重要更新。但是，所有新功能的开发都将仅在版本4中进行。 如果相关的话：我是该产品的单独开发人员，而且情况可能仍然如此。 编辑：我知道SVN的标签和分支。我想我需要的是在我的情况下使用标签和分支的最佳策略。
2
如果您只有SVN分支，是否应该打扰一下？
如果我们仅在Subversion中使用一个分支，我们是否还要打扰？我们不能只在行李箱上工作以加快速度吗？ 这就是我们使用Subversion开发的方式： 有一个行李箱 我们建立了一个新的发展分支 我们在该分支上开发了一项新功能 完成功能后，将其合并到主干中，删除分支，并从主干中创建新的开发分支 当我们要发布到生产环境时，我们会在行李箱中制作一个标签。错误修正是在该标签的分支上进行的。然后，此错误修正将合并到主干中。 这就是为什么在功能完成后我们创建了一个新的开发分支的原因。这样，错误修正会尽快包含在我们的新代码中。 下图应阐明： 现在，感觉这不是最有效的工作方式。我们在提交之前在本地进行构建，这大约需要5-10分钟。您可以理解，等待时间很长。 开发分支的想法是主干始终可以发布。但这在我们的情况下已不再是真的。有时，一项功能几乎已经准备就绪，并且一些开发人员已经开始编写下一个功能（否则，他们将围坐在一个或两个开发人员完成并合并的位置）。 然后，功能部件1完成后，将其合并到主干中，但包含功能部件2的某些提交。 那么，由于我们只有一个分支，我们是否应该还要烦扰开发分支？我一直在阅读有关基于主干的开发和逐个分支的信息，但是我发现大多数文章都集中在逐个分支的部分。我的印象是，重大变化将涉及多个版本。这不是我们遇到的问题。 你怎么看？我们可以在行李箱上工作吗？最坏的情况是（我认为），我们将不得不在主干中做一个标签，并挑选需要的提交，因为某些提交/功能尚未准备好投入生产。
10 svn  branching  tagging 
4
分支源代码和应用程​​序生命周期的最佳实践
我们是一家ISV小型商店，通常我们每个月都会发布我们产品的新版本。我们使用Subversion作为代码存储库，并使用Visual Studio 2010作为IDE。我知道很多人都在倡导Mercurial和其他分布式源代码控制系统，但是目前我还不知道如何从中受益，但是我可能是错的。 我们的主要问题是如何使分支和主干保持同步。 这是我们今天的工作方式： 发布新版本（在Subversion中自动创建标签） 继续研究将于下个月发布的主干 并且该周期每个月重复一次，并且运行良好。当需要发布紧急服务发布时会出现问题。我们无法从主干（2）上将其释放，因为它正在大力开发且不够稳定，无法紧急释放。 在这种情况下，我们将执行以下操作： 从我们在步骤（1）中创建的标签创建分支 错误修复 测试并发布 将更改推回主干（如果适用） 我们最大的问题是将这两个（主分支）合并。在大多数情况下，我们不能依靠自动合并，因为例如： 主干做了很多改变 合并复杂的文件（例如Visual Studio XML文件等）效果不佳 另一个开发人员/团队进行了您不了解的更改，您无法将其合并 因此，您认为最好的做法是使这两个不同的版本（分支和主版本）保持同步。你是做什么？
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.