在大型组织中使用Mercurial [英] Using Mercurial in a Large Organization
问题描述
一段时间以来，我一直在将Mercurial用于自己的个人项目，我喜欢它.我的雇主正在考虑从CVS切换到SVN，但我想知道是否应该推动Mercurial(或其他一些DVCS).
Mercurial的一个缺点是它似乎是围绕每个项目"只有一个存储库的想法而设计的.在这个组织中，当前CVS存储库中有数十种不同的可执行文件，DLL和其他组件，它们是按层次结构组织的.有很多通用的可重用组件，但也有一些特定于客户的组件和特定于客户的配置.当前的构建过程通常会从CVS存储库中获取一些子树集.
如果我们从CVS转到Mercurial，那么组织存储库的最佳方法是什么?我们是否应该有一个包含所有内容的庞大Mercurial存储库?如果不是，较小的存储库应有多细的粒度?我认为人们必须从许多不同的地方提取和推送更新会很烦人，但是如果他们不得不提取/推送整个公司的代码库，他们也会感到烦人.
有人对此有经验或建议吗?
相关问题:
AFAICS对任何DVCS的大部分抵制来自于不了解如何使用它们的人们.对于那些自远古以来就被锁定在CVS/SVN模型中并且无法想象其他事情的人们而言，经常重复的声明没有中央存储库"非常令人恐惧，特别是对于管理人员和高级(经验丰富的和/或愤世嫉俗的开发人员，他们需要强大的源代码跟踪和可重复性(也许还需要满足您有关开发过程的某些标准，例如我们曾经在我工作过的地方所做的工作).好吧，你可以有一个中央的祝福"仓库.您只是不受束缚.例如，对于一个子团队来说，很容易在他们的一个工作站上建立内部游乐场回购.
有很多方法可以给这只著名的猫蒙皮，坐下来仔细考虑自己的工作流程将使您受益匪浅.考虑一下您当前的做法以及几乎免费的克隆和分支为您提供的功能.您当前所做的某些工作很可能已经演变为可以解决CVS型模型的局限性；准备打破模子.您可能需要任命一两个冠军，以使每个人都轻松过渡.在一个大团队中，您可能想考虑将提交访问权限限制为 blessed .
在我的工作(小型软件公司)中，我们从CVS转到了hg，并且不再回头.我们主要以集中方式使用它.转换主要的(古老的和非常大的)存储库是一件很痛苦的事情，但是随您所愿，这一切都将成为现实，当它完成时-以后更改VCS会容易得多. (我们发现许多情况下，CVS转换工具无法弄清楚发生了什么；某人的提交仅部分成功，并且他们几天都没有注意到；解决了供应商分支机构；时间造成的普遍疯狂和精神错乱似乎消失了向后，没有从不同时区提交本地时间戳的帮助...)
我发现DVCS的最大好处是能够提早提交和经常提交，并且只有在准备就绪时才进行推送.当我达到各种进行中的里程碑时，我喜欢在沙子上打下一条线，以便在需要时可以倒退到某个地方-但是这些都不是提交给团队的，因为它们显然不完整以多种方式. (我主要是使用Mercurial队列执行此操作.)这一切与工作流程有关；我永远无法使用CVS做到这一点.
我想您已经知道这一点，但是如果您打算远离CVS，您可以做得比SVN好得多...
是整体还是模块?无论您使用何种VCS，无论是否进行分布式，任何范式转换都将非常棘手. CVS模型的独特之处在于它允许您在不检查存储库其余部分是否最新的情况下逐个文件提交(更不用说模块别名已引起人们的头痛).
- 使用整体存储库进行交易可能非常缓慢.您的vcs客户端必须扫描整个Universe的副本以查找更改，而不是仅扫描单个模块. (如果您使用的是Linux，请查看hg inotify扩展名(如果尚未这样做的话.)
- 单片仓库在提交(推动)时也会导致不必要的竞争条件.就像CVS的最新检查一样，但是适用于整个存储库:如果您有很多活跃的开发人员，并且频繁提交，那么这一步会很伤您.
我建议您值得努力摆脱整体，但要注意，这将增加构建系统的复杂性，从而增加自身的开销. (旁注:如果发现繁琐的工作，请将其自动化！毕竟，我们的程序员是懒惰的人.)将回购分解为所有组件模块可能太极端了.在少数存储库中，可能会找到中途的房子，并将相关组件组合在一起.您可能还会发现研究Mercurial的子模块支持很有用-嵌套存储库和<一个href ="https://www.mercurial-scm.org/wiki/ForestExtension" rel ="nofollow noreferrer">森林扩展(我都应该尝试着这两个方法).
在以前的工作场所中，我们有数十个组件，这些组件作为独立的CVS模块保存，具有相当严格的元结构.组件声明了它们所依赖的组件以及将要输出到哪里的内置零件；构建系统会自动编写make片段，以便您正在处理的内容可以提取所需的内容.通常，它运行良好，很少发生CVS最新检查失败的情况. (还有一个极其复杂但功能非常强大的构建机器人，它对依赖关系的解析工作最为轻松:如果已经有一个满足您要求的组件，它就不会重建该组件.此外，还包括组装安装程序和整个组件的元组件.使用ISO映像，您就可以轻松完成构建过程以及Sorcerers Apprentice的发展.您应该为此写一本书...)
I've been using Mercurial for my own personal projects for a while, and I love it. My employer is considering a switch from CVS to SVN, but I'm wondering whether I should push for Mercurial (or some other DVCS) instead.
One wrinkle with Mercurial is that it seems to be designed around the idea of having a single repository per "project". In this organization, there are dozens of different executables, DLLs, and other components in the current CVS repository, hierarchically organized. There are a lot of generic reusable components, but also some customer-specific components, and customer-specific configurations. The current build procedures generally get some set of subtrees out of the CVS repository.
If we move from CVS to Mercurial, what is the best way to organize the repository/repositories? Should we have one huge Mercurial repository containing everything? If not, how fine-grained should the smaller repositories be? I think people will find it very annoying if they have to pull and push updates from a lot of different places, but they will also find it annoying if they have to pull/push the entire company codebase.
Anybody have experience with this, or advice?
Related questions:
- Git-Based Source Control in the Enterprise: Suggested Tools and Practices?
- Distributed version control for HUGE projects - is it feasible?
AFAICS most of the resistance to any of the DVCSes comes from people not understanding how to use them. The oft-repeated statement that "there is no central repository" is very scary to people who have been locked into the CVS/SVN model since time immemorial and can't imagine anything else, especially so for management and senior (experienced and/or cynical) developers who want strong source code tracking and reproducibility (and perhaps also if you have to satisfy certain standards regarding your development processes, like we did at a place I once worked). Well, you can have a central "blessed" repo; you just aren't shackled to it. It's easy for a subteam to set up an internal playground repo on one of their workstations for a while, for example.
There are so many ways to skin the proverbial cat that it will pay you to sit down and think carefully about your workflow. Think about your current practices and the power that nearly-free cloning and branching gives you. It's likely that some of what you currently do will have evolved to work around the limitations of the CVS-type model; be prepared to break the mould. You will probably need to appoint a champion or two to ease everybody through the transition; with a big team you probably want to think about restricting commit access to blessed.
At my work (small software house) we moved from CVS to hg and wouldn't go back. We're using it in a mostly-centralised way. Converting our main (ancient and very large) repo was painful, but it will be whatever way you go, and when it's done it's done - it'll be a lot easier to change VCS later. (We found a number of situations where the CVS conversion tools just can't figure out what happened; where somebody's commit only partially succeeded and they didn't notice for days; resolving vendor branches; general madness and insanity caused by time appearing to go backwards, not helped by commit timestamps in local time from different timezones...)
The great benefit I've found of a DVCS is the ability to commit early and commit often and only push when it's ready. As I reach various work-in-progress milestones I like to lay down a line in the sand so that I have somewhere I can rewind to if need be - but these are not commits which should be exposed to the team as they are manifestly incomplete in myriad ways. (I do this mostly with mercurial queues.) It's all about the workflow; I could never have done this with CVS.
I guess you already know this, but if you're contemplating moving away from CVS, you can do so much better than SVN...
To monolith, or to module? Any paradigm shift is going to be tricky whatever VCS you work with, distributed or not; the CVS model is quite special in how it allows you to commit on a file by file basis without checking whether the rest of the repo is up to date (and let's not mention the headache that module aliases have been known to cause).
- Dealing with monolithic repositories can be pretty slow. Your vcs client has to scan your copy of the entire universe for changes, as opposed to just a single module. (If you're working on Linux, look into the hg inotify extension if you haven't already done so.)
- A monolithic repo also causes unnecessary race conditions when committing(pushing). It's like the CVS up-to-date check, but applied across the entire repo: if you have many active developers, committing frequently, this one will bite you.
I'd suggest that it's worth the effort to stay away from monolithic, but beware that it will impose its own overhead in terms of added complexity in your build system. (Side note: If you find something a tiresome chore, automate it! We programmers are lazy creatures, after all.) Splitting your repo out into all its component modules may be too extreme; there may be a halfway house to be found with related components grouped together among a small number of repositories. You may also find it useful to look into mercurial's submodule support - Nested Repositories and the Forest Extension (both of which I ought to try and get my head around).
At a former workplace we had several dozen components which were kept as independent CVS modules with a fairly regimented metastructure. Components declared what they depended on and which built parts were to be exported where; the build system automatically wrote make fragments so that what you were working on would pick up what it needed. It generally worked very well and it was quite rare to fail the CVS up-to-date check. (There was also a fiendishly complicated but extremely powerful build bot with a least-effort attitude to dependency resolution: it wouldn't rebuild a component if there was already one which met your requirements. Add to that meta-components which assembled installers and whole ISO images, and you have a good recipe for easy start-to-finish builds and for things going Sorcerers Apprentice. Somebody ought to write a book about it...)
这篇关于在大型组织中使用Mercurial的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
