<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000">
Tzafrir Cohen wrote:
<blockquote cite="mid:20091015211706.GD30903@pear.tzafrir.org.il"
type="cite"><br>
<pre wrap="">
I'm not sure I agree with you regarding version control systems.
Specifically distributed version control systems make the common case of
a repository for the project simple. Unlike Subversion, you don't need
to set up a separate server.
</pre>
</blockquote>
You do not need to set up a separate server in subversion. "svnadmin
create ~/svn ; svn co <a class="moz-txt-link-freetext" href="file:///home/sun/svn">file:///home/sun/svn</a>" is enough.<br>
<blockquote cite="mid:20091015211706.GD30903@pear.tzafrir.org.il"
type="cite">
<pre wrap="">And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
ex.c.orig and such.</pre>
</blockquote>
Has anyone compared git's performance with <a class="moz-txt-link-freetext" href="file://">file://</a> based svn? I'm not
sure that claim holds.<br>
<blockquote cite="mid:20091015211706.GD30903@pear.tzafrir.org.il"
type="cite">
<pre wrap=""> I think that demonstarting simple linear workflow
(no branches, no remote repositories) with git, bzr or hg could be handy.
</pre>
</blockquote>
Guy has already responded with some "shooting yourself in the foot",
but I'll elaborate. Git makes it exceedingly easy to reach situations
in which information is either actually lost, or is not technically
lost, but is unreachable without searching in internal log files. The
most problematic one to chance upon by accident is off branch commits
(where you revert to an old version, make changes and commit them by
mistake). I read somewhere an explanation of how to recover from this
situation. It started by explaining how lucky he was to have spotted
that that was what he did before he checked out another branch (if you
do, the only way to find your commits is the afore mentioned internal
log files). He then goes on to list the steps required to recover the
file, and ends with "viola! it's like magic", with a footnote stating
that "like magic" means it is a list of arbitrary and hard to remember
incantations in which getting the slightest thing wrong means a
catastrophe.<br>
<br>
At least the other case, where data is actually lost, is unlikely to
get at if you only work with one repository[1].<br>
<br>
In short, I'm with Guy on this one. Git is an extremely powerful tool,
but it is only useful once you master the right way to tread and where.
In other words - not a good choice for a novice[2].<br>
<br>
Shachar<br>
<br>
1<br>
The rebase operation actually changes the history. After a branch
rebase, the tree is reworked to look as if the branch has always
branched off the new rebase point. This means that the precise tree
layout before the rebase operation is no longer reachable. It is no
longer possible to check out the version that compiled fine before the
rebase.<br>
<br>
I don't remember the precise details at the moment to say whether every
rebase is like that, or whether it's only sometimes. I will say that,
in my book, a version control that allows an operation that is not
undoable is not a version control.<br>
<br>
As I write this, it occures to me that this may actually be the precise
same problem as the one I pointed above, and the previous end point for
the branch is still in the repository, it just doesn't have a name, and
if you know the commit's name, you can still check it out. That does
not change my above statement - it is a no-no for a version control
system.<br>
<br>
2<br>
In my opinion, also not a good choice for anyone who relies on
centralized backups (like a commercial company), not a good choice for
anyone who does not perform multi-commiters multi-versions development.
In other words, there are very few cases, aside from the Linux kernel
itself, where it IS a good choice. Also, I often find where even where
it is a good choice (such as Wine, where an off trunk personal
development branch might be long and convulted), it is not used
properly (the development model does not support a "git pull" and multi
commiters - only patch sending).<br>
<br>
In the android case, it is the best choice available (multiple
repositories, independently developed in parallel, with partial code
sharing between them), but has significant drawbacks (no support for
multiple repository checkouts, no support for partial tree checkouts)
which are worked around with a wrapper tool.<br>
<pre class="moz-signature" cols="72">--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
<a class="moz-txt-link-freetext" href="http://www.lingnu.com">http://www.lingnu.com</a>
</pre>
</body>
</html>