[jsword-devel] Git
DM Smith
dmsmith at crosswire.org
Sun Mar 25 12:44:25 MST 2012
Joe,
Yes I'd love some help here. I've already have a git repo on my home computer. Actually several, the initial git-svn and that converted from svn trunk/tags to git master/tags. I've been copying the latter to try to skinny it down. I'll put them up on the CrossWire server if it'd be at all helpful.
In Him,
DM
On Mar 25, 2012, at 3:28 PM, Joe Walker <joe at eireneh.com> wrote:
> On 17/03/2012 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.)
>
> I think, if we've got maven and it works then that's probably a good answer. The downside of maven is that it's a barrier to entry to a new person. The question is, would we take that risk to save the clone bandwidth.
> An interesting solution might be to have a separate 'binaries' repo where we could, from time to time clear history, whilst I think I understand git enough to know how this would work, we'd need to run some tests to make sure it's ok.
>
>> 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?
>
> I think there are 2 competing issues: control vs. engagement. Github wins hands down from an engagement point of view. It's where the 'cool kids' are. There is a feeling of control that comes with hosting your own server, but I'm really not sure it's worth it.
> Point of reference: Mozilla, which already has a massive investment in continuous integration servers, Mercurial repositories, etc - i.e. it has a full-time team dedicated to looking after a server infrastructure, is using Github for important projects like B2G (essentially a project to make Firefox run on Mobile phones, and able to make calls etc from web-apps.)
>
>> 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.
>
> If the answer to q4 is hosting-own-server, then permissions might not need to change, but it's probably your call as project-lead if they do.
> If the answer to q4 is Github, then the permissions model is different:
> * If the repo is owned by a person then it's a case of which pull requests the owner accepts, so there is no need for privileged users.
> * If the repo is owned by an organization then you can have a team own a repo. While I think it would be a good idea to have a Crosswire organization, I'm not sure that permissions are needed. Even in huge organizations like Mozilla's the team structure isn't actually *used*, it's there but basically overkill.
>
>> 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 think my answer would probably be to take the easiest option that saved the most history, and as full history is likely to be the default, we should perhaps take all of it.
> Perhaps the issue is what we do with binary resources. Can we / should we strip them out of the history? I think we'd need to have some better idea of the number involved before we decided that.
>
> Perhaps it would help if someone did a quick intended-for-delete conversion to see what we came up with? Would you like help?
>
> Joe.
>
>
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel
More information about the jsword-devel
mailing list