Tzafrir Cohen wrote:
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.
You do not need to set up a separate server in subversion. "svnadmin
create ~/svn ; svn co file:///home/sun/svn" is enough.
And it saves you a whole lot of time in saving ex1.c_1 , ex1.c_2,
ex.c.orig and such.
Has anyone compared git's performance with file:// based svn? I'm not
sure that claim holds.
I think that demonstarting simple linear workflow
(no branches, no remote repositories) with git, bzr or hg could be handy.
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.
At least the other case, where data is actually lost, is unlikely to get
at if you only work with one repository[1].
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].
Shachar
1
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.
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.
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.
2
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).
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.
--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com
_______________________________________________
Haifux mailing list
[email protected]
http://hamakor.org.il/cgi-bin/mailman/listinfo/haifux
