Bazaar 2.x VCS 会出现哪些问题？
我们即将从 CVS 迁移到 Bazaar。
在比较了 git、hg 和 bzr 的功能后，在我看来它们的功能是相似的。 集市 2。 x 基准显示其存储大小和速度介于 git 和 hg 之间。
另一方面，大多数人选择 git 或 hg（根据 ohloh 仅 < 0.5%的开源项目使用 Bazaar），所以我对 Bazaar 有点怀疑。
使用Bazaar时我们应该注意哪些问题？
（到目前为止，我遇到了一个问题：寻找类似于 git 的 tig 的键盘操作 GUI。我还没有找到。）
We are about to migrate from CVS to Bazaar.
After comparing features of git, hg and bzr it seems to me their capabilities are similar. Bazaar 2.x benchmarks show that its storage size and speed are between git and hg.
On the other hand most of people are choosing git or hg (according to ohloh only < 0.5% of the open-source projects uses Bazaar), so I'm a bit suspicious about Bazaar.
What problems should we expect when using Bazaar?
(So far I've had one problem: finding keyboard-operated GUI similar to tig for git. I haven't found one.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我对 Bazaar 的使用非常满意，但我对其他 VCS 没有太多经验。我的用例是一个 ASP.NET/C#/T-SQL 专有 Web 应用程序，拥有一个小型开发团队。
我预计从集中式 VCS 迁移到去中心化 VCS 时您会遇到一些成长的烦恼，尽管您可以通过使用集中式工作流程来缓解 Bazaar 的烦恼。
关于您关于键盘操作 GUI 的问题，我倾向于主要从命令行（使用 Powershell）使用 Bazaar。然而，我发现有些操作（详细日志读取、差异、注释）使用 GUI 更容易使用。
qbzr 插件允许我从命令行启动特定任务的 GUI。在大多数情况下，这仅意味着在命令前面添加“q”。
例如，在进行更改的工作树上尝试
bzr qdiff。 Bazaar Explorer 中提供的大多数工具都是 qbzr 工具。I've been quite happy using Bazaar, but I don't have much experience with other VCSs. My use case is an ASP.NET/C#/T-SQL proprietary web application, with a small team of developers.
I expect that you will have some growing pains moving from a centralized VCS to a decentralized VCS, though you can mitigate those with Bazaar by using the centralized workflow.
Regarding your question about a keyboard-operated GUI, I tend to use Bazaar mostly from the command line (using Powershell). However, there are some operations (detailed log reading, diffs, annotation) which I find are much easier to use with GUI.
The qbzr plugin allows me to launch GUIs for specific tasks from the command line. For the most part, this just means adding a 'q' in front of the command.
For example, try
bzr qdiffon a working tree with changes. Most of the tools available in Bazaar Explorer are just the qbzr tools.这取决于你对“问题”的理解。有些人每天都与 bzr 一起工作，从未遇到过任何使他们的工作变得不可能或非常困难的问题。这并不意味着 bzr 中没有奇怪的功能或怪癖。这确实意味着如果您了解自己在做什么，您就可以轻松地与 bzr 一起工作。
总的来说，bzr 是一种非常适合 VCS 的工作方式，但要有效地使用它，您最好了解自己的限制。
如果您开始使用 bzr，您应该了解分支、存储库、共享存储库和工作树之间的区别。共享存储库如何帮助您完成工作以及如何将分支保留在其中。您应该了解普通分支和结帐/轻量级结帐之间的区别。如果您想继续以 CVS 风格工作，您可能需要使用轻量级签出 - 这是 CVS 签出和计算机上本地工作空间的直接模拟。
使用 bzr，您可能会发现有点不清楚如何设置中央服务器并为团队的所有成员设置适当的访问权限。当然这是可行的，官方文档有一些例子。但正确的 ACL 需要 *-nix ssh 工具的大力帮助。
您应该了解，使用 bzr 引用某些修订版的最简单方法是使用其修订版号。但你应该知道，这个数字是特定于特定分支的，不同的分支可能有相同的数字 N 来指代不同的修订版。因此，有时您需要使用 bzr 中存在的唯一修订标识符，但该修订 ID 不是与 bzr 通信的默认方式，因为它很长并且不能像 git/hg 中那样轻易缩短到 8 个左右字符。修订号由主线概念决定，见下文。
自 2012 年 1 月起，您可能会遵守以下限制。
使用 bzr，您将被迫使用历史的主线概念。即，修订版的左父版本是特殊的，形成您的历史记录的主线，而您的合并修订版则形成合并的历史记录。默认情况下，控制台
bzr log显示主线历史记录，因为对于非常大的历史记录，显示包含合并修订的完整历史记录可能会慢一些。使用 bzr，您将不支持文件副本，即继续现有文件历史记录的新文件。
使用 bzr，您将不支持 CVS“模块”作为核心功能。但可以通过使用特殊插件（请参阅 bzr-externals 或 scmproj）来模拟它来为您完成大型项目配置工作。
该列表并不完整，但作为 bzr 的长期用户，这有时会影响我个人。
最后一点。 bzr 的主要问题是：几乎每个使用 git 或 hg 的人每次都会问你：“当他们公司里的所有人都使用 git （或 hg）时，你为什么选择 Bazaar”。
事实上，如果您计算一下 GitHub 上托管的项目数量，截至 2012 年 1 月，git 显然是其他 DVCS（git、hg、bzr 等）中的赢家。不仅因为 git 更优秀，还因为 GitHub 也非常好。
（git 用户注意：我尊重 git，但使用 bzr 作为我自己的选择。请不要向我解释为什么你认为 git 很好）。
It depends what you're understanding by "problem". Some people are working with bzr in day-to-day basis and never encountered any problem that make their work impossible or very hard. That does not mean there is no strange features or quirks in bzr. It does mean that you can comfortable work with bzr if you understand what are you doing.
In general bzr is very pleasant to work kind of VCS, but to use it effectively you'd better know your restrictions.
If you will start working with bzr you should understand what is difference between branch, repository, shared repository and working tree. How shared repository helps you in your work and how to keep branches inside it. You should understand the differences between plain branch and checkout/lightweight checkout. If you want to continue working in CVS style you might want to use lightweight checkouts -- that's direct analog of CVS checkout and local working space on your computer.
With bzr you may find it a bit unclear how to set-up central server and set a proper access rights for all members of your team. Of course that's doable and official documentation has some examples. But proper ACL will require big help from *-nix ssh tools.
You should understand that with bzr the simplest way to refer to some revision is using its revision number. But you should know that this number is specific to specific branch, and different branches may have the same number N referring to the different revisions. So sometimes you will neeed to use unique revision identifier which is present in bzr, but that revision id is not default way to communicate with bzr because it's long and cannot be easily shortened to 8 or so characters like in git/hg. That revision numbers are determined by mainline concept, see below.
As of January 2012 you may observe the following restrictions.
With bzr you'll be forced to use mainline concept of the history. I.e. the left-hand parent of the revision is special and forms mainline of your history, while your merged revisions make merged history. Console
bzr logby default shows you the mainline history, because showing the full history with merged revisions could be a bit slower for a really big history.With bzr you won't have support for file copies, i.e. new file that continues the history of existing file.
With bzr you won't have support for CVS "modules" as the core feature. But it could be emulated by using special plugins (see bzr-externals or scmproj) to do that big project configuration work for you.
The list is not full, but that is what from time to time affects me personaly as long-time bzr user.
And the final one note. The main problem with bzr you will have is: almost everybody who uses git or hg will ask you every time: "Why did you choose Bazaar, when all guys in their company use git (or hg)".
The truth is that git is clearly winner as of January 2012 among other DVCS (git, hg, bzr, etc.) if you will count how many projects hosted on GitHub. And not only because git is superior, but because GitHub is so nice as well.
(Note for git users: I respect git, but use bzr as my own choice. Don't explain me why you think git is good, please).