Re: [Simulavr-devel] Discussion: how to proceed with the develoment on GIT repo?

[ThomasK]

Hi @all,

so much fuss on the jungle and this guy, which causes that, isn't here! 
Shame on him! :-)

Ok, I have started this discussion and I should give a little summary 
till now:

There are 2 facts, which are common consensus: the (official and public) 
repo should be on savanah.org and we should not cut the history to old 
simulavr development (means hold old simulavr code in repo). I think, 
this was easy! ;-)

I'll left out in this post some points: making relases, extend tests, 
extend docu, who is the maintainer :-), how to communicate changes. This 
should be part of a following post, because there is one central point 
and I don't want to write a book ... ;-)

And it's possible to write a book about this! In my job I had to work 
with many VCS, I think, all well known, open source and commercial, 
exept Visual Source Safe (thanks good! ;-) ) and bazar (and arch too, 
but this isn't so well known) It has started with RCS and SCCS and in 
the moment I have to handle 3 different VCS systems with a few more 
projects, some are really big (commercial). So I can tell a little bit 
about it. ;-)

The first and important is: it's possible with EVERY VCS to shot 
yourself into feet, if you don't think about that, what you're doing! 
Sometimes it's possible to repair it, but some of this mistakes are 
burned into stone and you're blamed until the end of all days! :-) And 
Murphy is everywhere ...

There are 2 Types of VCS: The first, for example CVS, version files. It 
works, but my experience in many years and with a lot of (normal) users: 
it's "noisy"! Means: you forgot to commit a file change, you have mixed 
file versions as YOU like, but nobody else know, what you have done. You 
have created a path, but not right or you forgot a change. You have 
merged a patch, but not fully (it's not right, that CVS supports you on 
merging, not really) and so one.

The other type of VCS manages changesets. For example subversion, 
mercurial and git (and bazar too, as I remember). A changeset means: how 
to CHANGE A WHOLE PROJECT to come from current state to add a feature, 
fix a bug and others. It dosn't give a single file a dedicated version 
like CVS, but you can query the repo, on which changeset a special file 
is changed. So you'll get only releases for a whole repo. I had a 
discussion a few days before in my work about that. Some people miss the 
assigned version for a file. But why? It's right, that you need the 
version of a file for the first type of VCS to reconstruct a specific 
state. But not here, because a release means too a frozen state at this 
time, where the release is made! You need not the file versions, only 
the right release! But the most important advantage for this second type 
is: it's more intuitive for normal users (my experience with users, 
which had to start with VCS and are not programmers or hackers, 
especially if this one have used a VCS like CVS before, programmers and
hackers are a special species ;-) ). For me, the "noise" was significant 
less as for such like CVS!

What's the difference between subversion, mercurial and git, all 3 use 
changesets? Subversion needs a server for colaborative work (at least a 
file share) and only the server will hold all informations. 2 mercurial 
or git repos, which have the same root (and if you exchange all branches 
between the repos!) are identical and full functional repos! (think 
about it as a backup, in fact I use such repo's for backing up my local 
development! It isn't "expencive" and to get "checkpoints" in your 
development is a really good thing, especially, if you can easy review
your own changes on every time you want!)

There is another problem on subversion: subversion hasn't really 
branches. Branches are copies of a (sub)tree. On unix it's a more 
philosophic discussion, but not on windows, because windows hasn't such 
feature, like hard- or softlinks on unix. And because subversion uses 
also such copies for tagging you'll come in trouble in big projects on 
windows. subversion isn't bad, but there are better choices!

git and mercurial have also 2 more advantages: you can create "patch 
bombs", which hold also theres historical context, means, you know, when 
and from which origin a patch is made. This is a big help on merge. And 
my experience in merging is, that this works really good and mostly easy 
in mercurial and git. subversion had sometimes problems (but this mostly 
in special conditions!). And such patchbombs can be created really easy 
and also easy merged in. And with the possibility to get a new clone 
from whereever you want (from local file system or from net, for example 
github.com, the difference is only an other URL) you can try out any
operation on a repo, if you are not sure, to know, how you can do 
something without breaking all!

For administrators (or maintainers) there is one more: if 2 repo's have 
the same root, I can pull changes from different repo's, try out, 
compare, review, merge and then push to a next one! If we use git, then 
we could have a "official" repo on savanah, but developers could hold 
theirs own fork on github.com (or elsewhere, where it is possible to 
pull changes from), then a maintainer can pull that changes (for example 
a developer has announced in mailinglist, that he has finished 
something), review and if good, merge (if good made, then it's possible 
as "fast forward merge", so it dosn't need any intervention) and push to 
official repo, where developers can pull the official state into theirs 
own repos. So we can save our official repo from mistakes and secure to 
hold a official stable state and on the other hand, everybody can work 
on it without restrictions and developers have too the possibility to 
exchange work directly without any pain (or more pain as necessary ;-) ) 
Like a network, there is one official, which pulls from others, but all 
can exchange from where ever it's necessary.

So, as we know that savanah supports CVS, subversion and git, the 
question is: (of course in my opinion!) subversion or git.

Transfer old CVS repos to subversion or git is possible. Jörg wrote, 
that it is possible, to hold in parallel also a subversion or git repo. 
If this works, then I would propose to decide, which type (subversion or 
git) and to create such as fresh empty repo. The next one is to decide, 
what and from where data are to transfer to this new repo. For the old 
code base it's easy, there is only one. If we choose git, then I would 
propose to transfer onno's repo, maybe with changing the branches, the 
branch cvs-upstream on Onno's repo is the current state of official CVS 
repo, maybe we want to rename for that cvs-upstream to master and Onno's 
master-branch to a name, which reflects the development state. (but in
my opinion we can use Onno's master as the current stable)

Enough for now, (I've warned, I'll write a book ... ;-) ), cu, Thomas