[jsword-devel] Git

Sat Mar 17 16:42:27 MST 2012

On Mar 17, 2012, at 7:19 PM, Peter von Kaehne wrote:

> I have used two books to learn Git and both in their own way were
> fantastic. Gitmagic is one, you can download it. It comes in the Ubuntu
> repos as a book to download.
> 
> The other one is this:
> 
> http://progit.org/book/

This is the one I referred to. It is quite good.
> 
> I read Gitmagic to undrstand, but use pro git as reference.

I'll have to git (pun intended) gitmagic and read it.

> 
> FWIW, the CrossWire server has git installed, so there might be no real
> need to move the server - unless one especially wants to.

I might not understand it correctly. I was under the impression that the git package did not provide a managed server interface. And that the fundamental protocols in git need a bit more sugar.

> 
> Peter
> 
> 
> 
> On 17/03/12 20:52, DM Smith wrote:
>> Matěj (and others):
>> Well, I've read every thing you provided. Reading the "book" took several days and I had to re-read a few because they didn't make sense until I read the book.
>> 
>> Joe and Peter thanks for your input. That encouraged me to look at it sooner rather than later.
>> 
>> In order to go to git, I think there are a few things that need to be worked out.
>> 1) When? Should it be after the next release? Or can it be done now without impacting the release (other than a little bit of time)?
>> 2) How? I agree with you that 3rd party code and jar artifacts shouldn't be in the repository. It's not that big a deal with SVN as one only gets the top level, so each is included only once in the checkout, but with git every upgrade is included in the checkout. The question I have is how that should be done? How do we find them in svn? Where do we put what is currently needed? (I'm thinking the maven repository that we've stood-up on CrossWire, if it is not in maven central.)
>> 3) Who? We have a few users that have write permissions to JSword. Everyone else is read-only. We need this to continue in some form or another.
>> 4) Where? What is the best place to serve it? GitHub? Gitorious? Set up a server on CrossWire? If so which server? Gitosis? Gitolite? Other?
>> 5) What? How far back do we go? From the beginning, 1.0, 1.6? Over time we've refactored projects in Eclipse several times. It needs to include what is now in the JSword project, which is the merge of jsword-common into jsword. What should be done with the other projects? They can follow later into other repositories, but we will need to have a comparable build system on the CrossWire server that will pull all the code and build it.
>> 
>> I'm sure I'll have other questions later. Glad for help and encouragement.
>> 
>> More below:
>> 
>> On Mar 13, 2012, at 1:38 PM, DM Smith wrote:
>> 
>>> Thanks Matěj for the info. I will look into it. You've given me several good starting points.
>>> 
>>> In Him,
>>>   DM
>>> 
>>> 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).
>> 
>> Appreciate your input. I know at RedHat that Git is everywhere.
>> 
>>>> 
>>>>> 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.
>> 
>> Having read the book, I now appreciate this model.
>> 
>> The most common SVN model is that the next release is trunk. Each commit is expected to result in a stable trunk. If a feature will take iteration to achieve stability, it is done on a branch and merged into trunk when it is stable. When a release is done, it is tagged and also branched. The branch is treated as trunk for that release, accepting bug fixes and stable feature additions, being branched as needed for iteratively developed features.
>> 
>> I've used a minor variation of this, but it has not worked well in practice. My branches (multiple checkout of trunk) were local to my machine I attempted to checkin only when it was stable. 
>> 
>>>> 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).
>> 
>> I see now that the Git model would satisfy my shortcomings.
>> 
>>>> 
>>>> 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).
>> 
>> Thanks again. Also found a few other links on how to migrate from a typical SVN layout to a typical Git layout.
>> 
>>>> 
>>>>> 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.
>> 
>> Agreed. Humbly.
>> 
>>>> 
>>>>> 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.
>>>> 
>>>> Best,
>>>> 
>>>> Matěj
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> jsword-devel mailing list
>>> jsword-devel at crosswire.org
>>> http://www.crosswire.org/mailman/listinfo/jsword-devel
>> 
>> 
>> _______________________________________________
>> jsword-devel mailing list
>> jsword-devel at crosswire.org
>> http://www.crosswire.org/mailman/listinfo/jsword-devel
> 
> 
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel