代码之家 › 专栏 › 技术社区 › James Lin

SVN对我工作环境的改进建议

svn

James Lin · 技术社区 · 15 年前

另一个SVN指南问题,我知道。

我最近加入了一家新公司,它有几个网站。我们有几个开发人员和一个图形设计师,我们都使用SVN。我们每个人都有各自的工作副本和沙盒,并将所有内容提交给主干。

以下是我们面临的问题:

有时,多个ppl处理同一个特性/错误(例如,我和图形处理人员)。为了让我们同步我们的工作(例如让我看到新图片/css),图形人员需要提交他的更改,我必须更新我的工作副本。因此,在一天结束时,我们有很多修改要从主干合并到RC分支。
我们经常被要求实现一个特性,ok,finished,将代码提交到trunk。然后我们被要求修复一个bug(为了修复这个bug,它以某种方式使用了为这个特性编写的一些代码,没有人记得它)好的,bug修复,测试,提交bug修复到trunk。糟糕的部分是后来我们被告知,我们不会发布该功能,但需要发布错误修复。

还有一些场景,但我现在记不起来了。你们认为哪些变化会改善我们的流程?

詹姆斯

3 回复 | 直到 15 年前

aqwert 15 年前

我们团队使用设计师的一个好方法是,我们坐下来,迅速起草了一份“API”或基本代码合同,他可以在开发人员编写代码的同时进行设计。

试着经常整合到你的分支和主干上。如果签入中存在较大的间隙,则合并会变得更加困难(代码漂移)。合并工具只能帮你到目前为止。

bug确实发生在一个特性完成之后,没有人是完美的,但是要确保你有一个合适的bug跟踪系统,并将bug分配给最适合这个工作的人(通常是最了解这个特性的人)。

如果你有一个人知道这个特性,然后他去度假,你会发现团队中没有其他人知道它是如何工作的。在这种情况下,我发现最好尽可能多地与团队分享知识。如果您使用敏捷对等(pair)编程可以工作,也许代码审查。

HTH公司

kubal5003 15 年前

这可能是将svn更改为某种分布式svc(如mercurial或git)的好时机。我没有使用它们,但是根据我所读到的,当涉及到合并和分支时,它们的摩擦更小,这似乎是这里的问题。

Romain Hippeau 15 年前

我们的店是这样的。。。
后备箱只是生产中的东西。
如果开发人员需要创建一个更改,他会从主干创建一个分支。在分支中执行他的更改等。。。

一旦分支已经部署到生产和一些测试已经完成,然后刚刚投入生产的分支被重新整合到卡车中。
没有人接触主干,它总是生产的工作快照,除了部署后的一个小窗口。