Your best defense against excessive conflicts is a well-designed project. DRY code that separates concerns makes it possible to implement changes without tearing apart the entire project. If a change in core code requires updates in 50% of your source files, conflicts will be common.
When you make a change, tread lightly. Don't refactor a function that isn't part of your change requirements just because you don't like the look of it. It's perfectly reasonable for two developers to make changes to the same source as long as they're working on different concerns. SVN merging works very well as long as you're not trying to merge the same change implemented twice by different developers. Make refactoring part of a change plan.
Evaluate tools that sit on top of SVN and give your team another perspective on code changes. Trac and Fisheye are examples.
Judiciously use hook scripts to send out notifications or update a project wiki. This works better than reminding people to send notifications manually. Keep in mind, if you notify too often people will ignore your notifications.
Consider continuous integration so developers are given immediate feedback on their changes. Hudson is a nice tool that integrates with SVN. Continuous integration tools sometimes include integration to social tools as well. Hudson's build notifiers are examples.
Branches work well for changes that don't fit in a single release development cycle or when the changes will break the project for the rest of the team (always branch versus wait for weeks to check in). Opinions differ on when to branch. Just be sure your team agrees on an approach so the results are consistent.
Tags are used differently by different teams but by version number or release sounds reasonable.
Only the developers working on a branch's features should work in that branch.
Merge early and often from trunk to branch. This makes the final merge back to trunk much easier.
As long as you're making a change, evaluate distributed version control systems like Git or Mercurial before you make a decision.
I actually like Perforce, and I think Perforce does a better job at tracking merging than Subversion, but there are a few issues with Perforce and one is its integration with third party tools -- especially VisualStudio. And, that (plus the fact that developers don't really like it all that much) has made it hard to recommend at many sites.
If you're going to make a case to start moving to Subversion, I'd say your best tactic is the integration into your current tools, and the fact that Subversion has more integration points with other third party tools.
Here are some points I'd hit:
Subversion's integration with VisualStudio is cleaner and simpler.
Subversion integrates into more third party tools. Part of it is that Subversion is simpler and cleaner. There are no views. You don't have to mark files for editing. You can create a working directory anywhere you want. Part of it too is that Subversion is more popular, so most third party tools realize that if they want a shot at being used, they have to integrate with Subversion.
You can also point out the similarities between Subversion and Perforce, and that features you like about Perforce are in Subversion:
Both Perforce and Subversion practice interfile branching. That's Perforce's term for using directories as branches.
Both Subversion and Perforce use change lists/change sets (whatever term you use). In Perforce, change sets are in addition to the file versioning. In Subversion, the repository revision is the change set.
Both Subversion and Perforce practice atomic commits.
Best practice is looking beyond the tools, especially the version control system. You'll need defect tracking tools, a continuous build system, and a release repository. Best practice is about communication and trust:
Do you trust your build system?
Can you reliably create the build over and over?
Do you know what went into your build?
Does the QA team know what to test? Do they know what defects were fixed in a particular build?
Do the developers know what defects were found?
Do your developers know what features they should be adding, or the defects they need to fix?
How do you know if a particular build has been approved for release?
If you can show how you plan to answer these questions, you can build a strong case for your plans. Show how Subversion fits into these plans. Show how it works better with VisualStudio and how it will make the developer's job better.
I highly recommend that you look into Nant if you're building .NET apps. (I am assuming that you do your official build by opening up VisualStudio and hitting F5 or whatever does the build. If you're not doing this, you're way ahead of 90% of the VisualStudio sites I've seen). You can then use Hudson as your continuous build server. Hudson can also act as a release repository too since it can store the built artifacts. This means that people can easily access the official build.
The great thing is that through Hudson plugins, you can mark which builds are official releases, tag builds, etc. It integrates with Jira, Track, Bugzilla, MantisBT, and dozens of other defect tracking systems. It also works with Redmine which includes a defect tracking system, message board, charts, wiki, etc. That's another tool you can use.
The idea is to define the issues, define the solutions, and show how tools like Subversion can fit into them.
Remember that Best Practice isn't just a single methodology that can be repeated implemented over and over again. It's a way of understanding your project. It's making sure that everyone knows what is going on. It's making sure that everyone has complete trust in the process. It's making sure that you know exactly what is going on in your product.
There are all sorts of hints that people repeat over and over about best practices: Repeatability, catching defects early, automating everything, agile development, taking small bites instead of making massive changes, not breaking the build, etc. But, these are merely means to the end. Keep in mind the big picture.
I also find that it is absolutely important to sell the tools to the people who are using them, and that maybe what you see as a great advantage isn't so great for a developer. Developers want to be able to get the file they need, do their modification, and check in their change. They don't give a damn whether it is Perforce or Subversion or CVS. They don't care about changesets or atomic checkins. They don't care about Interfile branching. They simply want to know they're looking at the right file, and that when they make a change, it is delivered. If you're going to sell Subversion, you tell the developers how it will improve their process and make their lives easier.
Keep things simple too. A light hand with SCM is best. If people find the process arduous, they'll do their best to get around it.
Couriosity just sparkles out of your questions ;) - try not to get lost in doing/thinking too many things at a time.
So to answer them questions ..
1.Is there a way to prevent source conflicts in a social manner? If so, what is the best way to communicate about conflicting changes?
No mainstream Source Control Software that I am aware of brings a well implemented notification about possibly conflicting work before such work gets integrated into one another (merged). Apart from DRY and separation of concerns, as Corbin March mentioned, I think that "update daily", "commit early, commit often" and "branch late" (see below) are bread-and-butter practices.
Commiting early has its limits though. Syntax-Error Free and depending on your bugtracker / task-organizing system, only complete work-artifacts should get committed.
There really is not much social skill required to ask for help when you encounter a source conflict that you can not solve yourself, IMHO.
2.I’m planning to install a CMS into that server as well. So my teammates can write or communicate that they have branches and the like, but I don’t know if there other tools to track the historic health and bugs of our project.
This sounds like a pretty "distributed" approach. Not as in location but as in responsibility. You are creating software products and do some sort of release occasionaly do you? Therefore responsibility should increase and focus the further "downstream" it gets. The only branches the whole team should be familar with are the release branches for fixing things (no features there) and your mainline (trunk). All other things, feature-branches, integration branches, "backup" branches, private branches etc. are to be managed by those requesting or enforcing them. Why should you or colleague "A" care that colleague "B" branched the mainline to develop his experimental feature in peace? Colleague "B" by developing something groundbreaking, has the responsibility for his branch and to keep it COMPATIBLE with the mainline. Either constantly by merging changes from the mainline to his branch or before reintegration of his new code. Research integration branches if you want to know more.
As for the toolset .. Any bugtracker that is well integratable within SVN (Jira, trac, mantis, redmine ..) should do the job. But I do not understand how this part of the question relates to your conflict problems.
3.Even though my company practice the flat management approach, how can a rookie like me could convince or enforce social communication to senior programmers without breaking the invisible “senior” hierarchy?
I think you overestimate the amount of communication that is required in a well oiled workflow. What you mention indicates that you company lacks a workflow where you fight conflicts at the root (see 1. and 2.) which in your case makes more communication necessary, possibly creating unnecessarily high overhead. Having a CMS or some kind of "I work here" flagging-system might still be worthwhile to persue.
You indicated that some senior developers do not like to talk or socialize so much even in conflict cases where better they should. Don't let them get away with this by doing merges for them. Merges should be done by branch-owners. When conflicts aris, at least one of the conflicting sides has to decide upon the changes. Ideally both sides sit down on the diffs together but not a third party initially uninvolved with the source in question. Failure in conflict solving (selecting the wrong changes) might result in build breakage or, even worse, undetected bugs. People need to be aware.
Acting as mediator is not easy if senior developer "A" (merging mainline changes into his branch) curses about conflicts but does not talk to senior developer "B" whose mainline changes are in conflict with his. If it is not like crossing a line for you, try to talk to developer B and convince him to approach A to get the conflict resolved faster and less error-prone.
But again in the end it is developer "A"'s responsibility, not yours. You seem to give an example already to your co-workers. If that is not enough, try to carefully point out that not enough communication was the reason for a broken build when it happens. Maybe talk to one senior in private about your thoughts, be open but not accusive. A "we could to better" sounds nicer than "You guys are doing it wrong". And for you as a younger professional, sentences like "I would feel better about my code if you tell me when it conflicts with yours" might be more appropriate than "You should ask for a second pair of eyes from the right person when you get conflicts", even though the later is more straightforward.
If all this does not help, you might consider talking to your boss or team leader about the barriers you encounter. If he is not a fool he/she will listen.
For branching and tagging
1.I don’t want other teams to do branching to add a “Hello, World!” code into the program. I want to treat branching as something out of ordinary. Can anyone give me a rule of thumb on when to add create branch? When to merge?
For Merging see Question 4. below.
For Branching: You are perfectly right with trying to have as few branches as necessary. Branching comes at a price. Complexity, merging overhead etc. I tend to stick to "branch on incompatible policy". What policy you ask? Each of your main branches should have a set of documented rules attached to them.
Examples:
tag-2.0.4
no commit allowed
release-2
only fixes for existing features allowed
checkins should have release-quality
trunk
must compile/validate
Extending developed API allowed
renaming and deleting API prohibited
only complete bugtracker-issues
receives merges from release branches
feature-apirefactoring
may alter the developed API and break compatibility
pulling merges from trunk is feature-developers task
You see there is 3 fictive branches and one tag. The "feature-apirefactoring" is an example for a correctly applied "branch on incompatible policy".
Branches should be used to mitigate risks and increase efficiency by splitting different kinds of development activity. The branch policies individually define what development and risk potentials are acceptable. Want your trunk to be more stable? Define a new policy "Do not introduce W3C validator warnings". If groundbreaking development work has to break this rule for the sake of efficiency or to provide a fast proof-of-concept (we hack away first and cleanup later) it is a good candidate for its own branch.
Whenever you or a co-worker feels the urge to break a rule because it would be more simple or safer to NOT comply to a given policy, you are on a good way to discussing a branch-creation.
2.In what case branching a branch is a good idea? answered above I think :).
Some examples I encountered:
Branch stable branch from trunk when release gets prepared (no new features)
Branch integration branch from feature-branch when integration is too complex and time consuming
branch a "special edition" release branch from an allready stable release that has some exclusive features or certain possibly unstable differences for a special customer.
branch a translation-branch from your trunk that gets only wording changes and therefore can not break
There is dozen more. The more fine-grained your policies, the more exotic your branching can get.
3.For tagging, my understanding is that tag symbolize a static point of the program ( ie : v1.0, v2.5) is that correct?
Yes. For subversion it can be described as an alias. "/tags/1.7.2" could be the state of the project as it was at revision 30932. You can note down the revision number when a certain release was ready and compare your newer sources to it or create a checkout of this older state. Or you can use the easier to remember tag-name.
A tag in subversion also is nothing but a branch that does not receive any commits.
4.If I create a branch and start writing my changes, should my team-mates start syncing from my branch? Or should they still develop in the trunk? Or should they create another branch for themselves?
Short answer: When ever you are uncertain, use the trunk and do not merge (sync, push, pull) at all.
Long answer: In an ideal world there would be no need for branches as all developers get supplied with all changes the team checks in, instantly when it happens. In an ideal world these changes would not conflict with any developers own uncommitted work. Whatever a developer checks in inside my ideal world is also completely correct, free of flaws and glitches.
Alas, a programmers world is not perfect. Therefore you create branches to shield yourself from changes your co-workers do or you isolate your changes to not stain a clean mainline, sometimes both.
The direction of the flow of change (Your co-workers pull from you or you pull from your co-workers) depends on the riskyness expected in a branch. How much risk would it be to "pull" (merge) changes that get checked in to a release-branch? Looking at the policies defined above it should be bugfixes only. The risk seems low. For most release-branch scenarios merging from them into the turnk is absolutely necessary as you would have to refix the bugs by hand before the next release-branch gets created from your trunk.
How much risk of breaking your own precious work, or having to alter your own code, would lie in merging changes from feature-apirefactoring into your checkout of the trunk? You could develop new functionality, enhancing an api-call your co-worker owning the feature branch decided to replace with a completly new implementation. This might kill the mood.
Additionally to a policy per branch, you estimate their "firmness" and via that their position on the tofu scale.
A feature branch is "soft" as it is in constant flow, not well tested and mostly far away from any paying customer's eyes. It is therefore also more able to absorb changes. If things break you want them to break in "softer" branches.
Your trunk would be "medium" as it is not release ready but better tested than some remote feature branch. (let alone because more developers check out the trunk than feature branches). It might distract developers if huge compatibility-breaking changes appear in the trunk without proper integration, but normal sized checkins can soak in quite well.
Release branches are among the "firmest" branches as they are well established, tested and sometimes only hours away from productive usage. If you break this "slice of tofu" it is a bigger pain to stitch together. On the other hand you have a better feeling about what you are delivering in this branches and higher confidence (if not unit-tested proof) that it works well.
You should order the branches by their position on the tofu scale. Soft to the bottom, firm at the top.
tags (very firm)
release-2 (firm)
trunk (medium)
feature-apirefactoring (soft)
The best practice saying is "Merge down, Copy up".
Even better "Merge down, Copy up at stable state"
Merge down:
All commits that went in release-2, you should merge into the trunk as often as possible. (Bugfix-committer should do this)
All commits into the trunk, including merged down fixes from release branches, you should merge into your feature-branches as often as possible. (Feature-Owner should do this)
"Copy" up:
When work in a feature-branch is complete "reintegrate" it. Use the SVN --reintegrate merge or do a last merge down into the feature branch and then copy all relevant files. --reintegrate merge is highly recommended.
When you decide it is time to stabilize your trunk and target a new release soon, you branch your trunk into a new "release-3" for example. In SVN branching is copying and vice versa.
When your release is bugfixed, tested and working well enough you again copy up into a new release tag
While Subversion is a nice tool at what it does, its strong point certainly isn't merging. That is mainly because subversion has no mechanism that tracks merges - you cannot see in the history where something was merged.
So my suggestion is to either use a version control system that properly supports merging, or don't do it. You'll save yourself a lot of pain. Git appears to be most popular at the moment (and there appears to be Visual Studio integration, and a port of tortoise svn for Windows). However, Mercurial, Bazaar and the like are also viable choices.
These tools may be slightly more complicated than svn at first, but if you want to branch and merge on a regular basis, it'll be worthwhile.
But even with those tools, merging gets hard if a branch lives long enough. No tool in the world is going to help you with that.
So think hard if you really need to branch, or if you just do with and live with SVN (or perforce).
Not branching and merging is probably easier than it sounds. What you should do is setting up continuous integration (someone already mentioned Hudson) - this will let everyone know when something breaks the tests. If you have that in place, different members of the team can work on different features just fine, even on the same branch.
Continuous integration will work much smoother than fighting with branches and merge tool; though you should have a decent test suite.
If you think about branching for a "big change", don't. Instead develop the big change gradually on the trunk. This will be much easier than trying to integrate a heap of changes after a few weeks.
Finally, if you want to experiment, just branch away, no matter what the tool. Experimental branches will almost never be merged back to main development, anyway ;-) (And yes, I speak from experience)
The only scenario for which you really need advanced branches would be if you have to develop and track several versions/configurations of your product at the same time. In that case you definitively should go for an advanced version control tool.
I've never used perforce, so I can't comment on the differences (better or worse).
However, if you're a Visual Studio user, there is a lot of support for svn-integration (check out ANKHsvn (even works with latest vs2010) and TortoiseSVN a Windows client and shell extension.
Many great points have been made here, but I cannot stress how valuable a Constant Integration server is, which is easy to setup using something like CruiseControl.Net, which has tools like CCTray to accompany it...
Anyway, I diverge, and while this isn't the perfect answer, it should provide some food for thought.
I understand what it can be like to try and work out revision control - I love the analogy, I too sometimes feel like that.
These guys have got some really good advice already, but if you'd like something more practical - maybe with a demonstration - I'd recommend checking out our Subversion webinars. We are covering branching and merging in late January, with an introductory class followed by a more advanced session. This could be a really useful tool if you still feel a bit muddled, as there will be a practical demonstration.
We're also doing a 'Subversion Administration Best Practises' class too if this sounds like something you or one of your team might like to sit in on.
Here's the link: http://www.wandisco.com/webinar/subversion/training for you to have a look, and if anything takes your fancy sign up - it's totally free and we've tried to do classes on topics that developers have asked for. Hope this helps!
发布评论
评论（6）
排名不分先后：
In no particular order:
我实际上很喜欢 Perforce，而且我认为 Perforce 在跟踪合并方面比 Subversion 做得更好，但是 Perforce 存在一些问题，其中一个是它与第三方工具（尤其是 VisualStudio）的集成。而且，这一点（加上开发人员不太喜欢它的事实）使得它很难在许多网站上推荐。
如果您打算开始转向 Subversion，我想说您最好的策略是集成到您当前的工具中，而且 Subversion 与其他第三方工具有更多的集成点。
以下是我要强调的一些要点：
您还可以指出 Subversion 和 Perforce 之间的相似之处，以及 Subversion 中您喜欢的 Perforce 功能：
最佳实践是超越工具，尤其是版本控制系统。您将需要缺陷跟踪工具、持续构建系统和发布存储库。最佳实践是关于沟通和信任：
如果您能够展示您计划如何回答这些问题，您就可以为您的计划提供强有力的理由。展示 Subversion 如何融入这些计划。展示它如何更好地与 VisualStudio 配合使用以及它将如何使开发人员的工作变得更好。
如果您正在构建 .NET 应用程序，我强烈建议您研究 Nant。 （我假设您通过打开 VisualStudio 并按 F5 或其他进行构建的方式来进行正式构建。如果您不这样做，那么您就远远领先于我见过的 90% 的 VisualStudio 站点）。然后，您可以使用 Hudson 作为持续构建服务器。 Hudson 也可以充当发布存储库，因为它可以存储构建的工件。这意味着人们可以轻松访问官方版本。
最棒的是，通过 Hudson 插件，您可以标记哪些版本是正式版本、标记版本等。它与 Jira、Track、Bugzilla、MantisBT 和数十种其他缺陷跟踪系统集成。它还可以与 Redmine 配合使用，其中包括缺陷跟踪系统、留言板、图表、wiki 等。这是另一个工具你可以使用。
这个想法是定义问题、定义解决方案，并展示 Subversion 等工具如何适应这些问题。
请记住，最佳实践不仅仅是可以一次又一次重复实施的单一方法。这是理解您的项目的一种方式。它确保每个人都知道发生了什么。它确保每个人都完全信任这个过程。它确保您确切地了解产品中发生的情况。
人们一遍又一遍地重复关于最佳实践的各种提示：可重复性、及早发现缺陷、自动化一切、敏捷开发、小规模修改而不是进行大规模更改、不破坏构建等但是，这些只是达到目的的手段。牢记大局。
我还发现，将工具出售给使用它们的人绝对重要，而且也许您认为的巨大优势对于开发人员来说并不那么重要。开发人员希望能够获取他们需要的文件、进行修改并签入他们的更改。他们根本不在乎是 Perforce、Subversion 还是 CVS。他们不关心变更集或原子签入。他们不关心文件间分支。他们只是想知道他们正在查看正确的文件，并且当他们进行更改时，文件就会被交付。如果您要出售 Subversion，您需要告诉开发人员它将如何改进他们的流程并使他们的生活更轻松。
也让事情变得简单。轻手使用单片机是最好的。如果人们发现这个过程很艰难，他们会尽力绕过它。
I actually like Perforce, and I think Perforce does a better job at tracking merging than Subversion, but there are a few issues with Perforce and one is its integration with third party tools -- especially VisualStudio. And, that (plus the fact that developers don't really like it all that much) has made it hard to recommend at many sites.
If you're going to make a case to start moving to Subversion, I'd say your best tactic is the integration into your current tools, and the fact that Subversion has more integration points with other third party tools.
Here are some points I'd hit:
You can also point out the similarities between Subversion and Perforce, and that features you like about Perforce are in Subversion:
Best practice is looking beyond the tools, especially the version control system. You'll need defect tracking tools, a continuous build system, and a release repository. Best practice is about communication and trust:
If you can show how you plan to answer these questions, you can build a strong case for your plans. Show how Subversion fits into these plans. Show how it works better with VisualStudio and how it will make the developer's job better.
I highly recommend that you look into Nant if you're building .NET apps. (I am assuming that you do your official build by opening up VisualStudio and hitting F5 or whatever does the build. If you're not doing this, you're way ahead of 90% of the VisualStudio sites I've seen). You can then use Hudson as your continuous build server. Hudson can also act as a release repository too since it can store the built artifacts. This means that people can easily access the official build.
The great thing is that through Hudson plugins, you can mark which builds are official releases, tag builds, etc. It integrates with Jira, Track, Bugzilla, MantisBT, and dozens of other defect tracking systems. It also works with Redmine which includes a defect tracking system, message board, charts, wiki, etc. That's another tool you can use.
The idea is to define the issues, define the solutions, and show how tools like Subversion can fit into them.
Remember that Best Practice isn't just a single methodology that can be repeated implemented over and over again. It's a way of understanding your project. It's making sure that everyone knows what is going on. It's making sure that everyone has complete trust in the process. It's making sure that you know exactly what is going on in your product.
There are all sorts of hints that people repeat over and over about best practices: Repeatability, catching defects early, automating everything, agile development, taking small bites instead of making massive changes, not breaking the build, etc. But, these are merely means to the end. Keep in mind the big picture.
I also find that it is absolutely important to sell the tools to the people who are using them, and that maybe what you see as a great advantage isn't so great for a developer. Developers want to be able to get the file they need, do their modification, and check in their change. They don't give a damn whether it is Perforce or Subversion or CVS. They don't care about changesets or atomic checkins. They don't care about Interfile branching. They simply want to know they're looking at the right file, and that when they make a change, it is delivered. If you're going to sell Subversion, you tell the developers how it will improve their process and make their lives easier.
Keep things simple too. A light hand with SCM is best. If people find the process arduous, they'll do their best to get around it.
好奇心会从你的问题中迸发出来；）-尽量不要迷失在一次做/想太多事情中。
因此，要回答他们的问题..
1. 有没有办法以社会方式防止来源冲突？如果是这样，就冲突的更改进行沟通的最佳方式是什么？
据我所知，在这些工作相互集成（合并）之前，没有主流源代码控制软件能够提供有关可能冲突的工作的实施良好的通知。除了 DRY 和关注点分离之外，正如 Corbin March 提到的，我认为“每日更新”、“尽早提交、经常提交”和“延迟分支”（见下文）是最基本的实践。
但过早承诺也有其局限性。无语法错误，并且根据您的错误跟踪器/任务组织系统，只应提交完整的工作工件。
恕我直言，当您遇到无法自己解决的源冲突时，确实不需要太多的社交技巧来寻求帮助。
2. 我也计划在该服务器中安装 CMS。因此，我的队友可以编写或传达他们有分支等信息，但我不知道是否有其他工具来跟踪我们项目的历史运行状况和错误。
这听起来像是一种相当“分布式”的方法。不是因为位置，而是因为责任。您正在创建软件产品并偶尔进行某种发布，是吗？因此，责任应该增加并集中于它所到达的更“下游”。整个团队应该熟悉的唯一分支是用于修复问题的发布分支（那里没有功能）和主线（主干）。所有其他事物，功能分支，集成分支，“备份”分支，私有分支等都将由请求或执行它们的人来管理。为什么你或同事“A”要关心同事“B”分支主线以安静地开发他的实验功能？
同事“B”通过开发一些突破性的东西，对他的分支负责并保持它与主线兼容。要么不断地将更改从主线合并到他的分支，要么在重新集成他的新代码之前。如果您想了解更多信息，请研究集成分支。
至于工具集.. 任何可以很好地集成到 SVN 中的 bugtracker（Jira、trac、mantis、redmine ..）都应该可以完成这项工作。但我不明白问题的这一部分与您的冲突问题有何关系。
3. 即使我的公司实行扁平化管理方法，但像我这样的菜鸟如何能够说服或加强与高级程序员的社交沟通而不打破无形的“高级”等级制度？
我认为您高估了良好的工作流程所需的沟通量。您提到的情况表明，您的公司缺乏从根本上解决冲突的工作流程（参见 1. 和 2.），这在您的情况下需要更多的沟通，可能会产生不必要的高额开销。拥有 CMS 或某种“我在这里工作”标记系统可能仍然值得坚持。
您指出，一些高级开发人员不喜欢过多交谈或社交，即使在冲突情况下也是如此。不要让他们通过为他们进行合并而逃脱惩罚。合并应该由分支机构所有者完成。当冲突发生时，至少冲突一方必须就改变做出决定。理想情况下，双方一起坐下来讨论分歧，但不要让最初不参与相关消息来源的第三方。
冲突解决失败（选择错误的更改）可能会导致构建破坏，或者更糟糕的是，导致未检测到的错误。人们需要意识到。
如果高级开发人员“A”（将主线更改合并到他的分支中）咒骂冲突，但不与主线更改与他的冲突的高级开发人员“B”交谈，那么充当调解人并不容易。如果这对你来说不属于越界，请尝试与开发人员 B 交谈并说服他与 A 联系，以更快地解决冲突并减少出错的可能性。
但最终，这是开发人员“A”的责任，而不是你的责任。
您似乎已经给您的同事举了一个例子。如果这还不够，请尝试仔细指出沟通不足是构建失败的原因。也许可以私下与一位前辈谈谈你的想法，要坦诚，但不要指责。 “我们可以做得更好”听起来比“你们做错了”要好听。对于年轻的专业人士来说，“如果你告诉我我的代码与你的代码冲突，我会对我的代码感觉更好”可能比“当你得到正确的人时，你应该向合适的人寻求第二双眼睛”这样的句子更合适。冲突”，尽管后者更为直接。
如果所有这些都没有帮助，您可以考虑与您的老板或团队领导讨论您遇到的障碍。如果他不是傻子，他/她就会听。
用于分支和标记
1. 我不希望其他团队进行分支来添加“Hello, World!”代码到程序中。我想把分支视为不同寻常的东西。谁能给我关于何时添加创建分支的经验法则？何时合并？
对于合并，请参阅下面的问题 4。
对于分支：您尝试拥有尽可能少的分支是完全正确的。分支是有代价的。复杂性、合并开销等。
我倾向于坚持“在不相容的政策上分支”。你问什么政策？您的每个主要分支都应该附有一组记录在案的规则。
示例：
您会看到有 3 个虚构的分支和一个标签。 “feature-apirefactoring”是正确应用“不兼容策略分支”的示例。
分支机构应用于通过拆分不同类型的开发活动来降低风险并提高效率。分支机构政策单独定义了可接受的开发和潜在风险。想让你的后备箱更稳定吗？定义新策略“不要引入 W3C 验证器警告”。如果为了提高效率或提供快速的概念验证（我们先进行破解，然后进行清理），突破性的开发工作必须打破此规则，那么它是自己分支的良好候选者。
每当您或同事感到有违反规则的冲动时，因为不遵守给定的政策会更简单或更安全，那么您就可以很好地讨论创建分支。
2. 在什么情况下分支分支是个好主意？
我想上面已经回答了:)。
我遇到的一些例子：
还有十几个分支。您的策略越细粒度，您的分支就越奇特。
3. 对于标签，我的理解是标签象征着程序的静态点（即：v1.0、v2.5），正确吗？
是的。对于颠覆来说，它可以被描述为一个别名。 “/tags/1.7.2”可能是版本 30932 时的项目状态。您可以在某个版本准备就绪时记下修订号，并将较新的源与其进行比较，或者创建此旧状态的签出。或者您可以使用更容易记住的标签名称。
subversion 中的标签也只不过是一个不接收任何提交的分支。
4. 如果我创建一个分支并开始编写更改，我的队友是否应该开始从我的分支同步？或者它们仍然应该在树干中发育？或者他们应该为自己创建另一个分支？
简短的回答：当您不确定时，请使用主干并且根本不要合并（同步、推送、拉取）。
长答案：在理想的世界中，不需要分支，因为所有开发人员都会在团队签入的所有更改发生时立即获得。在理想的情况下，这些变化不会与任何开发人员自己未提交的工作发生冲突。无论开发人员在我的理想世界中检查什么，都是完全正确的，没有缺陷和故障。
唉，程序员的世界并不完美。因此，您创建分支来保护自己免受同事所做的更改的影响，或者隔离您的更改以免污染干净的主线，有时两者兼而有之。
变革流的方向（你的同事从你那里拉动，或者你从你的同事那里拉动）取决于分支机构的预期风险。
将签入到发布分支的更改“拉”（合并）会有多大风险？查看上面定义的策略，它应该只是错误修复。风险似乎很低。对于大多数发布分支场景，将它们合并到交接中是绝对必要的，因为在从主干创建下一个发布分支之前，您必须手动修复错误。
将功能重构的更改合并到主干的签出中会带来多大的破坏您自己的宝贵工作或必须更改自己的代码的风险？您可以开发新功能，增强拥有功能分支的同事决定用全新实现替换的 api 调用。这可能会破坏气氛。
豆腐秤
我想肯定是聪明人首先提到了“豆腐”秤。 （您可以通过谷歌搜索或阅读这些幻灯片 http://www. perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf）。
除了每个分支的策略之外，您还可以估计它们的“硬度”并通过它们在豆腐秤上的位置。
功能分支是“软”的，因为它处于持续流动中，没有经过充分测试，并且大多远离任何付费客户的眼睛。因此，它也更能够吸收变化。如果事情破裂了，你希望它们在“较软”的分支上破裂。
您的主干将是“中等”，因为它尚未准备好发布，但比某些远程功能分支经过了更好的测试。 （更不用说因为更多的开发人员检查主干而不是功能分支）。如果主干中出现巨大的破坏兼容性的更改而没有适当的集成，则可能会分散开发人员的注意力，但正常大小的签入可以很好地吸收。
发布分支是“最坚固”的分支之一，因为它们已经建立良好，经过测试，有时距离生产使用只有几个小时。如果把这块“豆腐片”弄碎了，缝合起来就更痛苦了。另一方面，您对在这个分支中交付的内容有更好的感觉，并且更有信心（如果没有经过单元测试的证明）它运行良好。
您应该按照豆腐秤上的位置对分支进行排序。底部柔软，顶部坚硬。
最佳实践说法是“向下合并，向上复制”。
更好的是“在稳定状态下合并，向上复制”
向下合并：
“复制”：
最后但并非最不重要的一点是阅读此最佳实践文档。再次由 perforce 伙计们;) http://www.perforce.com/perforce/papers/bestpractices .html
搜索 stackoverflow 或查看我的个人资料，了解更多 SVN 相关的问题与解答。答：
哦，如果知道你是如何成功实现你的正当抱负的，那就太好了。
周末愉快
C
Couriosity just sparkles out of your questions ;) - try not to get lost in doing/thinking too many things at a time.
So to answer them questions ..
1. Is there a way to prevent source conflicts in a social manner? If so, what is the best way to communicate about conflicting changes?
No mainstream Source Control Software that I am aware of brings a well implemented notification about possibly conflicting work before such work gets integrated into one another (merged). Apart from DRY and separation of concerns, as Corbin March mentioned, I think that "update daily", "commit early, commit often" and "branch late" (see below) are bread-and-butter practices.
Commiting early has its limits though. Syntax-Error Free and depending on your bugtracker / task-organizing system, only complete work-artifacts should get committed.
There really is not much social skill required to ask for help when you encounter a source conflict that you can not solve yourself, IMHO.
2. I’m planning to install a CMS into that server as well. So my teammates can write or communicate that they have branches and the like, but I don’t know if there other tools to track the historic health and bugs of our project.
This sounds like a pretty "distributed" approach. Not as in location but as in responsibility. You are creating software products and do some sort of release occasionaly do you? Therefore responsibility should increase and focus the further "downstream" it gets. The only branches the whole team should be familar with are the release branches for fixing things (no features there) and your mainline (trunk). All other things, feature-branches, integration branches, "backup" branches, private branches etc. are to be managed by those requesting or enforcing them. Why should you or colleague "A" care that colleague "B" branched the mainline to develop his experimental feature in peace?
Colleague "B" by developing something groundbreaking, has the responsibility for his branch and to keep it COMPATIBLE with the mainline. Either constantly by merging changes from the mainline to his branch or before reintegration of his new code. Research integration branches if you want to know more.
As for the toolset .. Any bugtracker that is well integratable within SVN (Jira, trac, mantis, redmine ..) should do the job. But I do not understand how this part of the question relates to your conflict problems.
3. Even though my company practice the flat management approach, how can a rookie like me could convince or enforce social communication to senior programmers without breaking the invisible “senior” hierarchy?
I think you overestimate the amount of communication that is required in a well oiled workflow. What you mention indicates that you company lacks a workflow where you fight conflicts at the root (see 1. and 2.) which in your case makes more communication necessary, possibly creating unnecessarily high overhead. Having a CMS or some kind of "I work here" flagging-system might still be worthwhile to persue.
You indicated that some senior developers do not like to talk or socialize so much even in conflict cases where better they should. Don't let them get away with this by doing merges for them. Merges should be done by branch-owners. When conflicts aris, at least one of the conflicting sides has to decide upon the changes. Ideally both sides sit down on the diffs together but not a third party initially uninvolved with the source in question.
Failure in conflict solving (selecting the wrong changes) might result in build breakage or, even worse, undetected bugs. People need to be aware.
Acting as mediator is not easy if senior developer "A" (merging mainline changes into his branch) curses about conflicts but does not talk to senior developer "B" whose mainline changes are in conflict with his. If it is not like crossing a line for you, try to talk to developer B and convince him to approach A to get the conflict resolved faster and less error-prone.
But again in the end it is developer "A"'s responsibility, not yours.
You seem to give an example already to your co-workers. If that is not enough, try to carefully point out that not enough communication was the reason for a broken build when it happens. Maybe talk to one senior in private about your thoughts, be open but not accusive. A "we could to better" sounds nicer than "You guys are doing it wrong". And for you as a younger professional, sentences like "I would feel better about my code if you tell me when it conflicts with yours" might be more appropriate than "You should ask for a second pair of eyes from the right person when you get conflicts", even though the later is more straightforward.
If all this does not help, you might consider talking to your boss or team leader about the barriers you encounter. If he is not a fool he/she will listen.
For branching and tagging
1. I don’t want other teams to do branching to add a “Hello, World!” code into the program. I want to treat branching as something out of ordinary. Can anyone give me a rule of thumb on when to add create branch? When to merge?
For Merging see Question 4. below.
For Branching: You are perfectly right with trying to have as few branches as necessary. Branching comes at a price. Complexity, merging overhead etc.
I tend to stick to "branch on incompatible policy". What policy you ask? Each of your main branches should have a set of documented rules attached to them.
Examples:
You see there is 3 fictive branches and one tag. The "feature-apirefactoring" is an example for a correctly applied "branch on incompatible policy".
Branches should be used to mitigate risks and increase efficiency by splitting different kinds of development activity. The branch policies individually define what development and risk potentials are acceptable. Want your trunk to be more stable? Define a new policy "Do not introduce W3C validator warnings". If groundbreaking development work has to break this rule for the sake of efficiency or to provide a fast proof-of-concept (we hack away first and cleanup later) it is a good candidate for its own branch.
Whenever you or a co-worker feels the urge to break a rule because it would be more simple or safer to NOT comply to a given policy, you are on a good way to discussing a branch-creation.
2. In what case branching a branch is a good idea?
answered above I think :).
Some examples I encountered:
There is dozen more. The more fine-grained your policies, the more exotic your branching can get.
3. For tagging, my understanding is that tag symbolize a static point of the program ( ie : v1.0, v2.5) is that correct?
Yes. For subversion it can be described as an alias. "/tags/1.7.2" could be the state of the project as it was at revision 30932. You can note down the revision number when a certain release was ready and compare your newer sources to it or create a checkout of this older state. Or you can use the easier to remember tag-name.
A tag in subversion also is nothing but a branch that does not receive any commits.
4. If I create a branch and start writing my changes, should my team-mates start syncing from my branch? Or should they still develop in the trunk? Or should they create another branch for themselves?
Short answer: When ever you are uncertain, use the trunk and do not merge (sync, push, pull) at all.
Long answer: In an ideal world there would be no need for branches as all developers get supplied with all changes the team checks in, instantly when it happens. In an ideal world these changes would not conflict with any developers own uncommitted work. Whatever a developer checks in inside my ideal world is also completely correct, free of flaws and glitches.
Alas, a programmers world is not perfect. Therefore you create branches to shield yourself from changes your co-workers do or you isolate your changes to not stain a clean mainline, sometimes both.
The direction of the flow of change (Your co-workers pull from you or you pull from your co-workers) depends on the riskyness expected in a branch.
How much risk would it be to "pull" (merge) changes that get checked in to a release-branch? Looking at the policies defined above it should be bugfixes only. The risk seems low. For most release-branch scenarios merging from them into the turnk is absolutely necessary as you would have to refix the bugs by hand before the next release-branch gets created from your trunk.
How much risk of breaking your own precious work, or having to alter your own code, would lie in merging changes from feature-apirefactoring into your checkout of the trunk? You could develop new functionality, enhancing an api-call your co-worker owning the feature branch decided to replace with a completly new implementation. This might kill the mood.
The Tofu Scale
I think it was the smart people from perforce that first mentioned the "tofu" scale. (you could google it or read these slides http://www.perforce.com/perforce/conferences/us/2005/presentations/Wingerd.pdf).
Additionally to a policy per branch, you estimate their "firmness" and via that their position on the tofu scale.
A feature branch is "soft" as it is in constant flow, not well tested and mostly far away from any paying customer's eyes. It is therefore also more able to absorb changes. If things break you want them to break in "softer" branches.
Your trunk would be "medium" as it is not release ready but better tested than some remote feature branch. (let alone because more developers check out the trunk than feature branches). It might distract developers if huge compatibility-breaking changes appear in the trunk without proper integration, but normal sized checkins can soak in quite well.
Release branches are among the "firmest" branches as they are well established, tested and sometimes only hours away from productive usage. If you break this "slice of tofu" it is a bigger pain to stitch together. On the other hand you have a better feeling about what you are delivering in this branches and higher confidence (if not unit-tested proof) that it works well.
You should order the branches by their position on the tofu scale. Soft to the bottom, firm at the top.
The best practice saying is "Merge down, Copy up".
Even better "Merge down, Copy up at stable state"
Merge down:
"Copy" up:
Last but not least read up this best practice document. Again by perforce guys ;) http://www.perforce.com/perforce/papers/bestpractices.html
Search stackoverflow or have a look at my profile for more SVN-releated Q & A.
Oh and knowing how you succeeded in your rightful ambitions would be nice.
Have a nice weekend
C
虽然 Subversion 是一个很好的工具，但它的强项肯定不是合并。这主要是因为 subversion 没有跟踪合并的机制 - 您无法在历史记录中看到某些内容被合并。
所以我的建议是要么使用正确支持合并的版本控制系统，要么不这样做。你将为自己省去很多痛苦。 Git 似乎目前最受欢迎（并且似乎有 Visual Studio 集成，以及 Tortoise svn 的端口（适用于 Windows）。但是，Mercurial、Bazaar之类的也是可行的选择。
这些工具一开始可能比 svn 稍微复杂一些，但是如果你想定期进行分支和合并，那么这是值得的。
但即使有了这些工具，如果分支寿命足够长，合并也会变得困难。世界上没有任何工具可以帮助你做到这一点。
因此，如果您确实需要分支，或者您只是使用 SVN（或被迫）并与之共存，请认真思考。
不分支和合并可能比听起来更容易。你应该做的是设置持续集成（有人已经提到过 Hudson） - 这会让每个人都知道什么时候发生破坏了测试。如果你做到了这一点，团队的不同成员就可以很好地处理不同的功能，即使是在同一个分支上。
持续集成会比与分支和合并工具战斗要顺利得多；尽管你应该有一个像样的测试套件。
如果您考虑进行“重大改变”，请不要这样做。而是在躯干上逐渐展开大的改变。这比几周后尝试整合一堆更改要容易得多。
最后，如果您想进行实验，无论使用什么工具，都可以离开分支。无论如何，实验分支几乎永远不会合并回主要开发;-)（是的，我是根据经验说的）
您真正需要高级分支的唯一场景是，如果您必须开发和跟踪您的多个版本/配置产品同时。在这种情况下，您绝对应该选择高级版本控制工具。
While Subversion is a nice tool at what it does, its strong point certainly isn't merging. That is mainly because subversion has no mechanism that tracks merges - you cannot see in the history where something was merged.
So my suggestion is to either use a version control system that properly supports merging, or don't do it. You'll save yourself a lot of pain. Git appears to be most popular at the moment (and there appears to be Visual Studio integration, and a port of tortoise svn for Windows). However, Mercurial, Bazaar and the like are also viable choices.
These tools may be slightly more complicated than svn at first, but if you want to branch and merge on a regular basis, it'll be worthwhile.
But even with those tools, merging gets hard if a branch lives long enough. No tool in the world is going to help you with that.
So think hard if you really need to branch, or if you just do with and live with SVN (or perforce).
Not branching and merging is probably easier than it sounds. What you should do is setting up continuous integration (someone already mentioned Hudson) - this will let everyone know when something breaks the tests. If you have that in place, different members of the team can work on different features just fine, even on the same branch.
Continuous integration will work much smoother than fighting with branches and merge tool; though you should have a decent test suite.
If you think about branching for a "big change", don't. Instead develop the big change gradually on the trunk. This will be much easier than trying to integrate a heap of changes after a few weeks.
Finally, if you want to experiment, just branch away, no matter what the tool. Experimental branches will almost never be merged back to main development, anyway ;-) (And yes, I speak from experience)
The only scenario for which you really need advanced branches would be if you have to develop and track several versions/configurations of your product at the same time. In that case you definitively should go for an advanced version control tool.
我从未使用过 perforce，所以我无法评论其中的差异（更好或更差）。
但是，如果您是 Visual Studio 用户，则有很多对 svn-integration 的支持（查看 ANKHsvn< /a> （甚至适用于最新的 vs2010）和 TortoiseSVN Windows 客户端和 shell 扩展
有很多优点 。在这里制作，但我无法强调持续集成服务器的价值，它很容易使用 CruiseControl.Net，它有 CCTray 之类的工具来配合......
无论如何，我有分歧，虽然这不是完美的答案，但它应该提供一些值得深思。
I've never used perforce, so I can't comment on the differences (better or worse).
However, if you're a Visual Studio user, there is a lot of support for svn-integration (check out ANKHsvn (even works with latest vs2010) and TortoiseSVN a Windows client and shell extension.
Many great points have been made here, but I cannot stress how valuable a Constant Integration server is, which is easy to setup using something like CruiseControl.Net, which has tools like CCTray to accompany it...
Anyway, I diverge, and while this isn't the perfect answer, it should provide some food for thought.
我理解尝试制定版本控制会是什么样子 - 我喜欢这个类比，有时我也有这样的感觉。
这些人已经得到了一些非常好的建议，但如果您想要更实用的东西（也许需要演示），我建议您查看我们的 Subversion 网络研讨会。我们将在一月下旬介绍分支和合并，先介绍入门课程，然后再进行更高级的课程。如果您仍然感到有点困惑，这可能是一个非常有用的工具，因为会有一个实际的演示。
如果您或您的团队之一听起来喜欢参加“颠覆管理最佳实践”课程，我们还会开设一门课程。
链接如下：http://www.wandisco.com/webinar/subversion/training供您查看，如果有什么需要您喜欢的，请注册 - 它是完全免费的，我们已经尝试针对开发人员要求的主题开设课程。希望这有帮助！
莱斯利
I understand what it can be like to try and work out revision control - I love the analogy, I too sometimes feel like that.
These guys have got some really good advice already, but if you'd like something more practical - maybe with a demonstration - I'd recommend checking out our Subversion webinars. We are covering branching and merging in late January, with an introductory class followed by a more advanced session. This could be a really useful tool if you still feel a bit muddled, as there will be a practical demonstration.
We're also doing a 'Subversion Administration Best Practises' class too if this sounds like something you or one of your team might like to sit in on.
Here's the link: http://www.wandisco.com/webinar/subversion/training for you to have a look, and if anything takes your fancy sign up - it's totally free and we've tried to do classes on topics that developers have asked for. Hope this helps!
Lesley