vcs - Daniel Jomphe on Diigo

It decouples the notion of checkpointing from publishing. In Subversion, those are the same thing
Git lets developers experiment with the whole of a project, without worrying about breaking things or losing work
2 more annotations...
- With Git running locally, developers push commits whenever they feel like and can fork and experiment to their hearts’ content. Those changes won't bother anyone “until you share [them],” said Vilain. “You share at the end of the day, after a day's work, when you've gone over the code a bit more.”
- “The reason that most of us use it is that it helps productivity,” said Scott Chacon, a developer at GitHub. “It provides cheap local branching. It works for really big repositories and really small repositories. And it’s free, and it’s easy to get.

14 Oct 08

Better SCM Initiative : Comparison

better-scm.berlios.de/...comparison.html - Preview

vcs dvcs git mercurial bazaar subversion comparison

12 Oct 08

I Can Haz Hardcore Forking Action

rob.cogit8.org/...an-haz-hardcore-forking-action - Preview

dvcs vcs git comparison

08 Oct 08

GitSvnComparsion - GitWiki

git.or.cz/...GitSvnComparsion - Preview

dvcs vcs comparison git svn

01 Oct 08

An introduction to git-svn for Subversion/SVK users and deserters

utsl.gen.nz/...intro.html - Preview

dvcs vcs git comparison svn mercurial bazaar

Not only is the implementation fast locally, it's very network
efficient, and the protocol for exchanging revisions is also very
good at figuring out what needs to be transferred quickly. This is
a huge difference - one repository hosted on Debian's Alioth SVN server took
2 days to synchronise because the protocol is so chatty.
Now it fits in 3 megs and would not take that long to synchronise
over a 150 baud modem.
Disk might be cheap, but my /home is always full -
git has a separate step for compacting repositories, which
means that delta compression can be far more effective. If
you're a compression buff, think of it as having an arbitrarily
sized window, because when delta compressing git is able to match
strings anywhere else in the repository - not just the file
which is the notional ancestor of the new revision.

This space efficiency affects everything - the virtual memory
footprint in your buffercache while mining information from the
repository, how much data needs to be transferred during "push" and
"pull" operations, and so on. Compare that to Subversion, which
even when merging between branches is incapable of using the same
space for the changes hitting the target branch. The results speak
for themselves - I have observed an average of 10 to 1
space savings going from Subversion FSFS to git.
48 more annotations...
- Perhaps somebody has already made a conversion of the project and put it somewhere
- git-svn fetch
- But people who use git are used to treating their repositories as a revision data warehouse which they use to mine useful information when they are trying to understand a codebase.
- importing the whole repository from Subversion
- git svn init
- git svn fetch
- If you like, you can skip early revisions using the -r
  option to git-fetch.
- make a local branch for development
- The name "foo" is completely private; it's just a local name you're assigning to the piece of work you're doing. Eventually you will learn to group related commits onto branches, called "topic branches", as described in the introduction.
- Say you want to take a project, and work on it somewhere else in a different direction, you can just make a copy using cp or your favourite file manager. Contrast this with Subversion, where you have to fiddle around with branches/ paths, svn cp, svn switch, etc
- Each of those copies is fully independent, and can diverge freely. You can easily push and pull changes between them without tearing your hair out.
- Each time you have a new idea, make a new branch and work in that.
- But anyway, that copying was too slow and heavy. We don't want to copy 70MB each time we want to work on a new idea. We want to create new branches at the drop of a hat. Maybe you don't want to copy the actual repository, just make another checkout. We can use git-clone again
- The -l option to git-clone told git to hardlink the objects together, so not only are these two sharing the same repository but they can still be moved around independently. Cool. I now have two checkouts I can work with, build software in, etc.
- But all that's a lot of work and most of the time I don't care to create lots of different directories for all my branches. I can just make a new branch and switch to it immediately with git-checkout:
- Once you have some edits you want to commit, you can use git-commit to commit them. Nothing (not even file changes) gets committed by default; you'll probably find yourself using git-commit -a to get similar semantics to svn commit.
- There is also a GUI for preparing commits in early (but entirely functional) stages of development.
- People used to darcs or SVK's interactive commit will like to try git add -i
- correcting changes in your local branch
- If it's the top commit, you can just add --amend to your regular git-commit command to, well, amend the last commit. If you explored the git-gui interface, you might have noticed the "Amend Last Commit" switch as well.
- You can also uncommit. The command for this is git-reset
- HEAD~1 is a special syntax that means "one commit before the reference called HEAD". HEAD^ is a slightly shorter shorthand for the same thing. I could have also put a complete revision number, a partial (non-ambiguous) revision number, or something like remotes/trunk. See git-rev-parse(1) for the full list of ways in which you can specify revisions.
- I sometimes write commands like `gitk --all `git-fsck | awk '/dangling commit/ {print $3}'`' to see all the commits in the repository, not just the ones with "post-it notes" (aka references) stuck to them.
- "Another" way to revise commits is to make a branch from the point a few commits ago, then make a new series of commits that is revised in the way that you want. This is the same scenario as before.
- I've introduced a new command there - git-cherry-pick. This takes a commit and tries to copy its changes to the branch you've currently got checked out. This technique is called rebasing commits. There is also a git-rebase command which probably would have been fewer commands than the above. But that's my way.
- Using Git opens the door to a bazaar of VCS tools rather than sacrificing your projects at the altar of one.
- keep your local branch up to date with Subversion
- The recommended way to do this for people familiar with Subversion is to use git-svn rebase.
- Note: before you do this, you should have a "clean" working
  tree - no local uncommitted changes. You can use git-stash
  (git 1.5.3+) to hide away local uncommitted changes for later.
- This command is doing something similar to the above commands that used git-cherry-pick; it's copying the changes from one point on the revision tree to another
- Better still is to bunch up your in-progress working copy changes
  into a set of unfinished commits, using git add -i (or
  git-gui / git-citool). Then try the rebase. You'll
  end up this time with more commits on top of the SVN tree than just
  one, so using Stacked Git you can "stg uncommit -n 4" (if you
  broke your changes into 4 commits), then use "stg pop" /
  "stg push" to wind around the stack (as well as "stg refresh" when finished making changes) to finish them - see
- in my experience stg is the best tool for
  rebasing
- Once you grok that,
  you'll only need to use stg and git-svn fetch.
- Ok, so you've already gone and made the
  commits locally that you wanted to publish back to the Subversion
  server. Perhaps you've even made a collection of changes, revising
  each change to be clearly understandable, making a single small change
  well such that the entire series of changes can be easily reviewed by
  your fellow project contributors. It is now time to publish your
  changes back to Subversion.
  
  The command to use is git svn dcommit. The d stands for delta
- git-svn won't let the server merge revisions on the fly; if there were updates since you fetched / rebased, you'll have to do that again.
- People are not used to this, thinking somehow that if somebody commits something to file A, then somebody else commits something to file B, the server should make a merged version with both changes, despite neither of the people committing actually having a working tree with both changes. This suffers from the same fundamental problem that darcs' patch calculus does - that just because patches apply 'cleanly' does not imply that they make sense - such a decision can only be automatically made with a dedicated continual integration (smoke) server.
- This is normally what I use in preference to rebase.
- This will merge all the commits that aren't in your ancestry, but are in the ancestry of the branch trunk (try setting rightmost drop-down in gitk to 'ancestor' and clicking around to get a feel for what this means), and make a new commit which has two parents - your old HEAD, and whatever commit trunk is up to.
- there are many shortfallings in git.
- Sadly, this model is in use by virtually every Subversion hosted
  project out there. And that is going to be hard to undo.
- It is possible to use git in this way (see the figure to the right) - but it's not trivial, and not default. In fact git itself is developed in this way, using feature branches, aka topic branches.
- Left: what darcs thinks when you start committing without marking tag points.
- Right: Subversion has a somewhat smaller brain...
- bzr comes with some great utilities like the Patch Queue Manager which helps show you your feature branches. With PQM, you just create a branch with a description of what you're trying to do, make it work against the version that you branched off, and then you're done. The branch can be updated to reflect changes in trunk, and eventually merged and closed.
- Windows support is good. Consistent implementation. Experience with the distributed development model. Friendly and approachable author and core team.
- Actually the models of git and bzr are similar enough that bzr could be fitted atop of the git repository model
- Mercurial is missing lightweight branches that makes git so
  powerful, and there is no content hashing, so it doesn't really do the
  whole "revision protocol" thing like git.
- If you're on Windows it's
  probably a lot easier to get going.

ONJava.com -- Sussman on DVCS, Van Zyl using GIT+SVN

www.oreillynet.com/...ans_on_distributed_versio.html - Preview

dvcs vcs comparison

Bazaar vs Git vs Mercurial — Version control systems comparison

versioncontrolblog.com/...index.html - Preview

dvcs vcs comparison comparator git mercurial svn bazaar

Mark Shuttleworth » Blog Archive » Merging is the key to software developer collaboration

www.markshuttleworth.com/...126 - Preview

dvcs vcs comparison

We must keep the cost of merging as low as possible if we want to encourage people to collaborate as much as possible. If a merge is awkward, or slow, or results in lots of conflicts, or breaks when people have renamed files and directories, then I’m likely to avoid merging early and merging often. And that just makes it even harder to merge later.
The beauty of distributed version control comes in the form of spontaneous team formation, as people with a common interest in a bug or feature start to work on it, bouncing that work between them by publishing branches and merging from one another. These teams form more easily when the cost of branching and merging is lowered, and taking this to the extreme suggests that it’s very worthwhile investing in the merge experience for developers.
1 more annotations...
- In CVS and SVN, the “time to branch” is low, but merging itself is almost always a painful process. Worse, merging a second time from another branch is WORSE, so the incentives for developers to merge regularly are exactly the wrong way around. For merge to be a smooth experience, the tools need to keep track of what has been merged before, so that you never end up redoing work that you’ve already solved. Bzr and Git both handle this pretty well, remembering which revisions in someone else’s branch you have already integrated into yours, and making sure that you don’t need to bother to do it again.

29 Sep 08

that's not the whole picture.

First and foremost you forgot the disconnected part. You can't commit to Subversion unless you can reach the repository, which is often in a server over the Internet.

Also, each developer isn't restricted to one branch. He very often has a lot of them. Right now I have 28 separate branches of Qt in my workstation: they range from previous stable releases of Qt (to test regressions and fixes with) to branches I created to start working on fixing tasks to research projects.
And that's just my private branches. When I am collaborating with other people in projects, I have more branches. For one project right now in Qt, we are tracking 4 or 5 different branches, each with a different "theme": optimisations, new features, animations, etc. And there's an extra branch which is the merger of all those "theme branches", so that we can get a feel of what it will be when it's done.
2 more annotations...
- Finally, you're also forgetting the ability to undo, redo, and modify your work. Once you commit to Subversion, it's there for life. Removing something from the repository means dumping and reloading it. With a Git, you can undo your commits, change them, squash them together without problems. (You can do that after you've published them, technically, but you shouldn't)
- people are asked to only commit stuff to trunk when they are done with it. Which for refactors and bigger things means it may be a week or more before you can commit it.
  
  And due to that requirement, thiago's post becomes very relevant. Those tools are essential to a scalable workflow.

InfoQ: Distributed Version Control Systems: A Not-So-Quick Guide Through

www.infoq.com/dvcs-guide - Preview

dvcs vcs git comparison

Major reason is that branching is easy but merging is a pain
Subversion has no History-aware merge capability, forcing its users to manually track exactly which revisions have been merged between branches making it error-prone.
5 more annotations...
- No way to push changes to another user (without submitting to the Central Server).
- Subversion fails to merge changes when files or directories are renamed.
- Each working copy is effectively a remoted backup of the codebase and change history, providing natural security against data loss.
- Experimental branches – creating and destroying branches are simple operations and fast.
  Collaboration between peers made easy.
- have a look at

Workflows - Bazaar Version Control

bazaar-vcs.org/Workflows - Preview

dvcs vcs git comparison

Intro to Distributed Version Control (Illustrated) | BetterExplained

betterexplained.com/...ed-version-control-illustrated - Preview

dvcs vcs git comparison

David Bock's Weblog : Weblog

www.jroller.com/...estioning_subversion_practices - Preview

dvcs vcs git comparison

You see, branches and tags in CVS are different things. But in subversion, they are the same - they are just copies of the trunk into one of those directories. In CVS, these events are temporal... that is, they affect a file at a given point in time. In Subversion, while they still apply to a particular version of a file, branches and tags are spatial... that is, they exist as copies of the trunk, just copied into a specially designated place.

This 'branches' and 'tags' convention in subversion is actually limiting, and somewhat false. Since they are really the same thing, I can modify the contents of a 'tag', which is impossible in CVS. I have come to believe that while this convention is useful for projects converted from CVS, it is misleading, limiting, and harmful for new projects. I want a new convention
As long as I am coming up with a new convention, what other things might I want to address? First, I like to have a place 'close to the code' where management documents like requirements, meeting minutes, and the like can be stored, but these kinds of things rarely (if ever) need to be branched. I also like Maven's convention that allows for directories of different kinds of source to be part of the same project. Taking all this into account, here is my new convention:
```
/project
  /code
    /head
      /rails
      /java
    /versions
  /design
  /management
```
1 more annotations...
- Gone are the 'branches' and 'tags' directories, in favor of a single 'versions' directory that should always contain copies of the head with meaningful version names.

Discipline...

dot.kde.org/1219928790 - Preview

dvcs vcs git comparison

And then git... If I look at what happens in the linux kernel development community, I see the best developers being permanently busy with merging, merging, merging and merging and very little else. And, actually, a scheme where we only seldom integrate, where every developer at one, infrequent, moment publishes their branch for merging sounds like a recipe for integration hell, no matter how developer-friendly and good at branching and merging a tool might be.
The Linux kernel development process is not very similar to KDE's of course. The overhead of what's going in is higher, it's quite formal and bound to specific persons that decide it all. KDE is quite different in that it's team-based, so potentially making it easier to share code in those teams and merge it upstream as it becomes interesting for others until finally bugs have been shaken out and it's ready to go into trunk.

Daniel Jomphe's Library tagged vcs → View Popular

PEP 374 -- Migrating from svn to a distributed VCS

An Illustrated Guide to Git on Windows

Gnome DVCS Survey — GitHub

Why Git is Better Than X

Git changes how developers manage source code versions - SD Times On The Web

Better SCM Initiative : Comparison

I Can Haz Hardcore Forking Action

GitSvnComparsion - GitWiki

An introduction to git-svn for Subversion/SVK users and deserters

ONJava.com -- Sussman on DVCS, Van Zyl using GIT+SVN

Bazaar vs Git vs Mercurial — Version control systems comparison

Mark Shuttleworth » Blog Archive » Merging is the key to software developer collaboration

Git - SVN Crash Course

Derek Slager: DVCS Myths

SVN 1.5

InfoQ: Distributed Version Control Systems: A Not-So-Quick Guide Through

Workflows - Bazaar Version Control

Intro to Distributed Version Control (Illustrated) | BetterExplained

David Bock's Weblog : Weblog

Discipline...

Selected Tags

Related Tags

Sponsored Links

Top Contributors

Groups interested in vcs

dvcs-vs-vcs

git-vs-mercurial-vs-bazaar

learning-git

Version Control

Software VCS

Version Control Info