There are many reasons to create branches in the Update/Commit model and Distributed Version Control really excels in an environment with many branches. Take the examples in the previous post:
In Distributed Version Control, each of these would be “repository/working directories” (repository for short). I put these terms together, because in distributed version control, your repository contains both the complete history and metadata and the working directory in which to edit the files. What this means is that you can branch the code without anyone else knowing. It also means, you *have* to branch in order to get a working directory to edit files. This encourages developers to segregate their tasks into branches and then merge each feature back to a central repository when the work is done.
On the server you might have the following repositories:
- Trunk
- Released (which contains v1.0, v1.1, and v2.0 labels)
On your local machine you might have the following repositories based on the Trunk repository on the server:
- Foo Feature
- Bar Feature
Once a feature is complete, you can push the changes to the Trunk repository and then delete your local feature’s repository.
This link has a more detailed explanation on how distributed source control works.
How funny! This is the same evloution of approch to the management of version control i’ve been through myself. Distributed Version control – well well. Love the 4 part post. Keep it up Clay.
Thanks for the feedback. I wrote this when I was working with coworkers who liked and understood the “Checkin/Checkout” model. We’ve progressed through each step over about 4 years and people see the light and we’re using a distributed source control system now.
I would add that Distributed Source Control has another advantage over branching/merging. In branching and merging you have to decide on the structure of the branches. For instance my branch “Foo Feature” must merge to “Trunk” (where Trunk = testing), and then Trunk will merge with Release when it is released. That means that if Foo feature is merged to Trunk, and then management decides that Bar feature should be released next, you are in a difficult spot.
With distributed source control, the decision isn’t needed. You, in a sense, create the testing branch each time you want to start testing with all the features you want to include in the next release since any branch in a distributed source control can merge with any branch.
With Team System, I find the delay before editing as it checks the file out annoying, plus it really is only feasible to use Visual Studio (or Eclipse if you paid enough), since manually checking out a file to edit is way too time consuming. There are also difficult merging scenarios — like creating the same file in two branches and then merging them together.
With SVN, I find it annoying I have to jump to SVN to handle file renames. Folder renames are even more difficult.
With Mercurial, I can make *any* change to the files, and then when I’m ready to commit, Mercurial can handle any change. It equally handles any merging scenarios like creating the same file in two branches and merging them together, and if the files are identical, it automatically resolves the merge.
All of these Mercurial features allow me to write code ignoring source control until I’m ready to commit.
世界一流ブランドコピー超人気専門店
信用第一、良い品質、
低価格は私達のち残りの切り札です。
送料は無料です(日本全国)!
ブランドコピー 代引きN品をご 購入の方は、こちらへ.
弊社は正規品と同等品質のコピー品を低価で お客様に提供します!
すべての商品は品質2年無料保証です。
人気の売れ筋商品を多数取り揃えております。全て激安特価でご提供.お願いします.迅速、確実にお客様の手元にお届け致します。実物写真、付属品を完備しております。低価格を提供すると共に、品質を絶対保証しております。商品の交換と返品ができます。ブランドコピーバッグの誠実と信用の店24時間以内に出荷し、3～4日に到着して、 https://www.tentenok.com/product-5427.html