dmsmith at crosswire.org
Tue Mar 13 10:38:43 MST 2012
Thanks Matěj for the info. I will look into it. You've given me several
good starting points.
On 03/13/2012 01:07 PM, Matěj Cepl wrote:
> 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
> 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.
More information about the jsword-devel