[jsword-devel] Git

Matěj Cepl mcepl at redhat.com
Tue Mar 13 10:07:09 MST 2012

On 13.3.2012 16:26, DM Smith wrote:
> No serious discussions. The major issue is that there needs to be a
> master copy of the code, with all others ultimately being branches
> of it. Since git can be layered over SVN, we can have SVN be the
> authoritative, master copy and the layers of git be the branches.
> Finally, there needs to be a small number of people that are
> gatekeepers of the master.

I have no bones in this fight, just to note that git doesn't have to
mean that each git repository is equal to each other. There is the
Linus' repo to which only he has an access, there are special central
repositories for all other projects I know about to use git/mercurial
(Xorg, Mozilla, Gnome projects).

> This is more a problem with how we are using SVN. The model that we
> should use is to have trunk be the next release and tag each release
> from it (as we are now doing), but also to create a release branch
> for each tag when needed to solve bugs, add translations, etc.

That's just a question of the workflow. Master should be the same as
trunk in SVN, meaning that only the accepted official commits should be
there. ALL development should be done on topical branches, which only
when accepted should be merged into the master branch of the centralized
repo (from which all other masters should be pulled).

See for more

http://schacon.github.com/git/gitworkflows.html (manpage provided with git)
http://progit.org/book/ch5-1.html (the best book on Git, online as well
as offline)
http://nvie.com/posts/a-successful-git-branching-model/ (I don't follow
this one, but it is one of the best thought-through ones).

> In the case of av11n, it should have been done on a branch because
> of how disruptive it is. Basically, a feature that cannot become
> stable in a few weeks shouldn't be implemented in trunk.

NO feature should be developed on master.

> I understand how this increases collaboration, but I have some
> concerns. They might be/probably are based on a misunderstanding of
> how git works. I think that by layering git over svn, my concerns
> probably are satisfied.

This is not a good solution. Meaning, certainly it is better than just
SVN, but everybody using git allows much more sophisticated cooperation
(e.g., topical branch in the centralized repository ... everybody can
cooperate on it, but it is not the official master yet), merging between
two git-svn-generated repositories is not that great (as git cannot use
commit IDs for identification of the shared points).

In the end you would really need a blessed official git-svn RO mirror.
When you have that there is really no point

> Part of my problem is that I know and am comfortable with svn. I'm
> not eager to try something else, especially with a non-trivial
> learning curve, if the problem can be solved simply in svn.

There are tons of documentation for former SVN users
(http://git-scm.com/course/svn.html is usual startpoint) and it is
really not that difficult. I have seen (and helped a bit) to my
colleague migrating all his work related work from SVN to Git (he is a
maintainer of a large sub-project inside of JBoss). Week later, he was 
on fire for git; he even bought with his own money a special computer, 
just to host his complete copy of all JBoss repos cloned via git-svn. 
Three months later, whole open source JBoss is primarily hosted on 
github (https://github.com/jboss; I believe maintained enterprise 
versions are still in SVN inside of VPN). I am not saying I was the only 
git fan helping them to see The Light (here in Red Hat it is only git 
all the time everywhere), but the speed with which he, as an experienced 
professional SVN user, (and his colleagues) made and embraced the shift 
was impressive even for me.

> Maybe it is time I took a serious look at git.

Indeed. If you need any help in this department, feel free to ask.



http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

Home is where ~/.bashrc is.
    -- from Usenet

More information about the jsword-devel mailing list