[Haifux] [W2L] Call for lecturer + "Linux guru"

[Shachar Shemesh]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://haifux.org/pipermail/haifux/attachments/20091016/2e6b6fef/attachment.html