Re: svn versus git

[Robin Rosenberg <robin.rosenberg.lists@dewire.com>]

onsdag 13 december 2006 23:00 skrev Andy Parkins:
[...]
> svn checkout::
> Checkout a working copy from a repository.  You may check out an
> arbitrary revision.
> git clone::
> git checkout::
> Git, of course, is different from subversion, as the whole repository is
> always available.  git-checkout is nearest in concept to svn-checkout
> though.  It changes the current working directory to a particular
> branch.  You may not checkout an arbitrary revision.  git-clone might
> also be considered as an svn checkout analog.  However,
>
> Subversion wins.  The output from Subversion's checkout is clear.  The
> output from git-clone gives output that is only understandable by
> someone familiar with git internals.
I'd say svn clone is the nearest equivalent as it does the initial fetch of 
data, no checkout is necessary after clone. it checks out master. Then
you git-checkout to switch branch, which corresponds to svn switch.

> svn commit::
> Pushes changes to the upstream respository from your working copy.
> git commit -a::
> Saves changes to the working copy as a new revision in the local
> repository.
>
> The need for "-a" (or not) because of git's staging area (the index)
> here makes it more confusing than svn-commit for new users.  However,
> the ability to do "git --amend" more than makes up for it.  Fixing a
> typo in your last log message is difficult in subversion.  Also, git's
> commit message template is much better: both uses the output of their
> status commands which is far clearer in git than in Subversion.
>
> Git wins.
You'll need to push too in order to get a copy in a central repository. 
git-commit stays locally, and you need a place to push to. If your SVN
repo isn't local this does not apply. git gives more freedom here.

> svn copy::
> Duplicate something in working copy or repository, remembering history.
> cp A B; git add B::
> Git doesn't have a direct equivalent of svn copy.  It's arguable whether
> it needs it once the user knows they can git-add so easily.
>
> Git wins.  Git's ability to detect copies after-the-fact, mean that a
> git-copy isn't necessary.
svn copy is more like git checout -b, i.e. it's primary purpose is not 
to "copy" things, it is to create branches. You generally do not copy
code (I hope).

> svn move::
> Move and/or rename something in working copy or repository.
> git-mv::
> Move or rename a file, directory or symlink.
>
> Git wins.  The two are equivalent except that git can do multiple moves
> in one command, just like normal "mv".  So "git mv src/* newsrc/" works
> while "svn mv src/* newsrc/" doesn't.  Additionally, if you forget to do
> moves with git and instead use the command line, you can easily use
> "update-index" to tell git about the move after the fact.  In subversion
> you have to undo all the moves and do them again with subversion.  This
> makes it inconvenient to use tools like "rename" to do regexp moves.
In svn this also renames a branch.

> svn switch::
> Update the working copy to a different URL.
> [no git equivalent]::
> git is distributed and can fetch from any number of remote repositories.
> The URL can be typed on the command line of git-fetch, or can be given a
> shortcut as a "remote".  If we're talking about a single repository
> (which we have to to compare against subversion), the repository is
> local anyway.
>
> Git wins.  Command is unnecessary.
svn switch corresponds to git-checkout. I don't think you can change the URL
unless the new URL actually points to the same repository.

> Discussion
> ----------
[...]
>  - svn revert: it's not easy to revert a single file in git; especially
>    once we bring the index into play.  Restoring a single file in the index
>    to HEAD while leaving the rest of the index AND the working directory
>    untouched requires something like
>    ----------------------------------------------------
>    git-ls-tree file | git-update-index --index-info
>    ----------------------------------------------------
>    Which isn't simple enough for a typical user.
Typically the user want to restore the index AND the working directory. 
Comparing typical workflows is more interesting than finding exact 
equivalents.