Ubuntu中文论坛

This story covers the individual hacker named Barry. Barry likes to work independantly on free software projects. He's got a small pile of small free software projects. Barry hasn't been using revision control on his projects because he felt that doing so wouldn't be worth the effort.

Unfortunately for poor Barry, one of his ten users has complained about a bug that has been in his code for the last couple features. This bug wasn't complicated, but was spread throughout the code in lots of little pieces that made it difficult for Barry to track down. Barry, realizing that he doesn't want to repeat this type of effort again, decides to move to using a revision control system.

Barry wanted to get his code controlled as easily as possible. He wanted all of the bells and whistles of a RCS system, but didn't want to pay the cost of setting up RCS servers. Thusly, he chose Bazaar-NG. Barry decided to start controlling a project that he forked years ago, something called Tuxpuck.

The first thing that Barry did was to get a copy of his own sources, which he put into a directory named tuxpuck (if you are following along with bzr yourself, feel free to import something you've got, perhaps by running cp -a /etc/init.d ~/tuxpuck). He then performed the following actions: Barry was pretty happy with this. He decided to give bzr a few more commits so that he could get a feel for how commits went: Barry, like much of us, leads a hectic life. He wanders off for a few days and comes back, unable to remember what he did. To get around this, he runs "bzr log:" This pleases Barry quite a bit, mostly because Barry hasn't worked with a revision control system a bit (Note: This is my imaginary friend and I can make him easy to please if I want!)

However, this doesn't please Barry for too long; he wants more than just to be able to to save changes. What he'd really like to do is to work on two things at the same time, so that he get a feel for branching: What he's just done now is tell bazaar-ng to make a copy of his old tuxpuck branch and make a new one in the newpuck directory. These two branches are absolutely identical, except for location. In a moment of inspiration, Barry realizes this means that he could have made a copy of his branch in other ways... He could have run "cp -a tuxpuck newpuck", he could have rsynced the branch to another machine, or even done a copy by transcribing by hand, if he had been so inclined.

This is cool and all, but what's the point of having a two branches that are exactly the same? Thusly, Barry makes some changes to newpuck: Barry, like many people, gets distracted for a few days and walks off. When he comes back he can't remember how tuxpuck and newpuck are different. To figure out how the two trees are different, he runs: *

Note: The branch: revision specifier is available on 0.7 and later versions. If Barry were using 0.6 or earlier, he'd need to do something like:

Barry decides that he likes the changes that he did to the newpuck branch the other day and decides to merge it into his main tuxpuck branch. Thusly, he ran the following: Sure enough, bzr merged the changes that he made in the newpuck branch into the tuxpuck branch. He wonders, though, what happens with slightly more complicated files. Barry decides to try a slightly more complicated test: Now he's ready to try something a little different: He's going to try and make the a different change to the same file in two different branches: Barry is now comfortable knowing that my_brag is different in two different places. But can bzr merge them? So far so good! So Barry commits and tries it the other way: "This seems pretty cool!" Barry says to himself. He takes a quick look at the my_brag in newpuck, and sure enough, both typos have been fixed. But what would happen if Barry had tried to merge two branches that had changes in the same place? This results in something called a conflict. A conflicted file is a bit of a headache to deal with that is a bit difficult to explain at this point. We'll get to that later.

This wraps up the first chapter of the Bzr chronicles. In this chapter you learned, by actually performing, the following things:

* How to import a new project into bazaar-ng
* How to branch in bazaar-ng
* How to check the differences between two branches in bazaar-ng
* How to merge between two branches in bazaar-ng

这是一个关于一名名叫Barry的黑客的故事，Barry喜欢一个人努力于自由软件项目。他有一小堆不算太大的自由软件项目。Barry并没有使用版本控制软件在他的项目里，因为他觉的并不是那么有价值去为版本控制付出努力。

终于不幸降临在可怜的Barry身上，10个用户抱怨一个bug,这个bug出现在他的代码的最后几个特性中。这些bug并不复杂，但是由于这些bug的扩散，让很多一小块一小块的代码与Barry的初衷越离越远。Barry意识到事情的严重性，他不想再次浪费他的努力，于是他觉定使用版本控制工具。

Barry希望他的代码管理可以尽量的容易，他希望有个花哨的远程集中管理器，并且他不希望在配置这个管理器身上浪费太多的精力，因此，他选择了Bazaar-NG。Barry开始了一个新的项目，这个项目受到了控制，它的名字叫做Tuxpuck。

Barry所进行的第一件事就是产生了一份自己已有代码的拷贝，他把这些代码放到一个叫做tuxpuck的目录里。然后他是是这样做得： Barry对这次尝试非常的满意，他决定再给bzr一些委托，于是他开始摸索应该怎么作: Barry,像我们大多数一样，在生活中充满了忙乱，他在辛苦了几天后终于归来了，可是他忘了他做过什么，于是他输入"bzr log:" 这个让Barry有点很满意的感觉，毕竟Barry并没有在一个版本控制工具下工作过。

然而，这并没有让Barry满意太久，他希望更多的功能，不仅仅是记录更改。因为他是非常喜欢在同一段时间内进行两件事的，所以他稍微的体验了一下分支功能：

他刚才所做的是要让bzr产生一个tuxpuch的分支，这个分支独立的放在另外一个叫做newpuck的目录下，这两个分之是完全相同的，除了他们所处的位置，在一瞬间的灵感后，Barry明白这意味着他可以通过新的方法产生一个程序的拷贝，他可以"cp -a tuxpuck newpuck"，他也可以通过rsync这个拷贝到别的机器，他也可以一边开发一边翻译，如果他有这个想法的话。

一切都是那么的cool，可是什么是使这两个分支一致的重点呢？因此，Barry为newpuck制造了一点不同： Barry，和大多数人一样，经过了心烦意乱的几天，当他回到他的工作时，他不能记得tuxpuck和newpuck的区别了，为了估计出这两个分支的情况，他运行了下面的命令： Note:Barry显然在使用版本超过0.7的bzr，因此他可以直接那么作，如果在0.6版或者更早的版本上，他需要运行这些命令: Barry决定，他要把一些newpuck的变化合并到tuxpuck里面去，因为他喜欢那些变化，于是，他运行了下面的命令： 当然，bzr出色的合并了两者，他很惊讶，然而，如果是一些更加发杂的文件会怎么样呢，Barry决定来实验一下： 现在他准备使一份相同的文件，产生两种不同的修改: 现在Barry明确的知道两者之间的不同，但是bzr能成功合并他们吗？ 到目前为止，一切看上去都不错，所以Barry决定用不同的方式尝试委托它： “这简直太棒了！”Barry自言自语着，他匀速的检查了一下newpuck的my_brag，果然，两者的错误都被消除了。 但是，当需要合并的两个分支在同一个地方有了两种不同的改变时，事情会怎么样呢？这是一个很麻烦的冲突，我们将在以后的故事里介绍解决他的方法。

在这个关于bzr的小故事里，你应该可以领略到bzr的大概面貌，而且你肯定掌握了下面的事：
* 怎么插入一个新的项目到bzr里
* 怎么产生分支
* 怎么检查两个分支之间的不同
* 怎么合并两个分支

dongmh现在在哪儿呢？
签名里还是ubuntu5。10。看来好久没来了。
是兴趣转移了还是忙于高考呢？

转移到了wiki
http://wiki.ubuntu.org.cn/bzr初学者的经历