Distributed version control? How winter 2007 of you. Let's try distributed bug tracking.(distract.wellquite.org)
distract.wellquite.org
Distributed version control? How winter 2007 of you. Let's try distributed bug tracking.
http://www.distract.wellquite.org/start
2 comments
Haha, I'd bet real money that > 75% of people who read this site still use a centralized VCS, most likely SVN. The pace of change is glacial.
This is not a troll - could someone please explain to me why I might use Git instead of SVN? With Git, wouldn't I still need to merge all the streams through some "offical" repository before I release version x of the product? And if I'm doing that, then what's the difference?
The point of the distributed approach is precisely that you eliminate the need for a "official" repository.
If it seems pointless, consider a scenario where you have three separate teams (A, B, C) working on a product.
In a centralized approach, you'd want to create a branch for each team, have them working on their exclusive branch and have each of them make a merge to the main branch. If you are responsible for the "main" repository, you need to make three merges, one for A, one for B, one for C. This is hard and gets even harder when the number of teams grows.
In a distributed approach, each team is able to pull stuff from the other teams any time and as they see fit. In that case, if you are the responsible for the "main" repository, you could establish a policy where you will only pull code from the C tree, and let C be responsible for pulling from B, and B from A. With this approach, each team is responsible only for one merge.
If it seems pointless, consider a scenario where you have three separate teams (A, B, C) working on a product.
In a centralized approach, you'd want to create a branch for each team, have them working on their exclusive branch and have each of them make a merge to the main branch. If you are responsible for the "main" repository, you need to make three merges, one for A, one for B, one for C. This is hard and gets even harder when the number of teams grows.
In a distributed approach, each team is able to pull stuff from the other teams any time and as they see fit. In that case, if you are the responsible for the "main" repository, you could establish a policy where you will only pull code from the C tree, and let C be responsible for pulling from B, and B from A. With this approach, each team is responsible only for one merge.
And yet, even if you are antisocial, and would never dream of setting up a baroque collection of three independent teams, git is awesome.
You can have repositories all over the place. Creating or cloning them is about as hard as copying a file. You can make one for any directory in a few seconds. You can create them wherever you want on your hard drive. You can back them up by dragging and dropping.
You can create one repository for (e.g.) the official release version of Drupal, clone that to another repository that also includes some important modules, then clone that repeatedly every time you start a project. To upgrade Drupal, upgrade the first repository and then pull the changes forward to all the others.
The branching support works very well and is easy to figure out. If you touch a few files and then have second thoughts, you can stash all your changes in a branch and then go back to the original state. You can screw around with your source code with complete confidence.
Git repositories are non-magical -- each one is fully contained inside a plain-old directory. If you do somehow manage to screw one up beyond recognition, just restore an old version from backup. You won't lose anyone else's changes, because each local repository is exclusively yours. You won't run the risk of corrupting other projects, because each repository is local and includes just one project.
No server configuration, unless you really want to share with the world (and gitosis makes that easy).
You can have repositories all over the place. Creating or cloning them is about as hard as copying a file. You can make one for any directory in a few seconds. You can create them wherever you want on your hard drive. You can back them up by dragging and dropping.
You can create one repository for (e.g.) the official release version of Drupal, clone that to another repository that also includes some important modules, then clone that repeatedly every time you start a project. To upgrade Drupal, upgrade the first repository and then pull the changes forward to all the others.
The branching support works very well and is easy to figure out. If you touch a few files and then have second thoughts, you can stash all your changes in a branch and then go back to the original state. You can screw around with your source code with complete confidence.
Git repositories are non-magical -- each one is fully contained inside a plain-old directory. If you do somehow manage to screw one up beyond recognition, just restore an old version from backup. You won't lose anyone else's changes, because each local repository is exclusively yours. You won't run the risk of corrupting other projects, because each repository is local and includes just one project.
No server configuration, unless you really want to share with the world (and gitosis makes that easy).
Thank you very much for the breakdown. I still don't see the benefit, however. Saying that you don't have an official repository is just semantics, because someone will in fact be responsible for the final merge, and that's going to be the official repository, whether you call it that or not. Furthermore, the code all has to get merged in the end. How does it simplify thing to merge from C --> B --> A --> Official, rather than just have everyone merging against an official repository?
Again, I'm not trolling - I ask these questions because I'm working somewhere right now where they use Clearcase, which admittedly is a horrible, horrible, horrible tool, but which is being used in my current environment very much like a DVCS. Everyone feels "productive" because they can merge their branch into other folks' branches on an as needed basis. But the end result is freakin' chaos from the point of view of product management, because it takes - literally - weeks to get a completely merged codebase containing the entire product. How does a tool like Git help matters?
Again, I'm not trolling - I ask these questions because I'm working somewhere right now where they use Clearcase, which admittedly is a horrible, horrible, horrible tool, but which is being used in my current environment very much like a DVCS. Everyone feels "productive" because they can merge their branch into other folks' branches on an as needed basis. But the end result is freakin' chaos from the point of view of product management, because it takes - literally - weeks to get a completely merged codebase containing the entire product. How does a tool like Git help matters?
I think this may help
http://video.google.com/videoplay?docid=-2199332044603874737
http://video.google.com/videoplay?docid=-2199332044603874737
That's Linus' talk. It's fun, but for a more nuts-and-bolts approach you should perhaps start with Randal Schwartz's talk instead.
I also recommend the Peepcode screencast on git.
I also recommend the Peepcode screencast on git.
I think the talk might be good for people who don't see what the big deal is, or how being distributed leads to interesting possibilities.
Ho hum. We've had this since 1996 with a custom Lotus Notes/Domino application.