Re: should biojava svn be moved to github ?

I thought people here might be interested to know that Rosetta is currently
switching from SVN to GIT. They have a pretty complicated build
configuration, but GIT seems up to the challenge. They had an interesting
list of benefits drafted on the internal Baker
wiki<http://docu.bakerlab.org/doku.php?id=proposed_changes:switch_to_git>I
thought would be interesting to share:

End User ( You only use the binaries)

   - Your database version will always match the binary version ( so no
   more segfaults because your database is different)
   - You can switch to other people's patched databases easily!

 Infrequent Developers( A commit every so often )

   - Everything from End User applies
   - You can update every day *SAFELY*
   - You can work locally, and never actually commit your changes if you
   don't want to ( but still benefit from having version control, rollbacks,
   etc.)
   - You benefit from other people's uncommited changes( see below )
   - Committing your small change is much easier because you don't
*MERGE*with trunk, you
   *PATCH **ON TOP* of trunk
   - Workflow stays pretty much the same

 Frequent Developers

   - Everything from Infrequent Developers applies
   - You can create many local branches, one for each feature or bugfix
   - When you commit, you commit a whole branch at a time, which makes
      reading history very easy
       - You can update your local branch on *TOP* of the trunk
   - By applying your local branch as a series of patches, conflict
      resolution is MUCH easier (no enormous merge conflict resolutions)
       - Everyone's local branch is completely visible to you, allowing you
   to share uncommited changes very easily
   - Workflow changes quite a bit, but for the better

 Repository Manager

   - Other than setting up initial users, you don't have to do anything
   - Automated testing handles rejections of commits


Cheers,

Spencer



On Fri, Aug 3, 2012 at 8:54 PM, Spencer Bliven <[email protected]> wrote:
>
> I'm all for it, provided (as others have mentioned)
>
> Eclipse support is now good enough for day-to-day stuff (maybe falling
back to command line for complicated merges and branches)
> It integrates with Maven for releases
>
> I was also slightly concerned with the overhead of storing the full git
repository. Surprisingly, a git checkout doesn't have that much more
overhead than a SVN checkout, despite storing full histories for each file.
>
> Biojava trunk checkout
> Bare files: 29MB
> SVN checkout: 60MB (107% overhead)
> GIT checkout: 74MB (155% overhead)
>
> However, GIT did take substantially longer to download from github than
SVN took from the biojava server. Since server speeds likely differ
significantly, that's not apples-to-apples, but it might be realistic.
>
> SVN checkout: 1m9.333s
> GIT checkout: 4m50.871s
>
> Overall I'm in favor of making the switch.
>
> -Spencer
>
>
>
>
> On Fri, Aug 3, 2012 at 4:11 PM, Michael Heuer <[email protected]> wrote:
>>
>> Thanks, Andreas, that is a good document.
>>
>> One problem we might face is that some of the repository operations
>> are performed by the maven release plugin itself and then we're at the
>> mercy of the implementers of that plugin to have done it correctly.
>>
>>    michael
>>
>>
>> On Fri, Aug 3, 2012 at 6:00 PM, Andreas Prlic <[email protected]> wrote:
>> > Hi Michael,
>> >
>> > About the question how to cut a release from a distributed repository:
>> > I found this article an interesting read:
>> >
>> > http://nvie.com/posts/a-successful-git-branching-model/
>> >
>> > Andreas
>> >
>> >
>> > On Fri, Aug 3, 2012 at 8:57 AM, Michael Heuer <[email protected]>
wrote:
>> >> -0
>> >>
>> >> I use github for quite a few personal things and mercurial via Google
>> >> Code on a different project and while I think there are some benefits
>> >> to the distributed model I don't understand how it would work from the
>> >> point of view of a release manager.  Does anyone have any pointers to
>> >> documentation on how to manage and cut a release from a distributed
>> >> repository?
>> >>
>> >> With the current svn mirror on github, developers can already fork and
>> >> create pull requests, they just need to be applied back to the svn
>> >> repository.  Is there any advantage to moving the repository to
>> >> github?  Are there any people who will start contributing because the
>> >> repository is on github that are unwilling to do so with the current
>> >> model (send patches to the mailing list or issue tracker)?
>> >>
>> >> My current client just started a new project on Google Code and we had
>> >> a similar conversation:  subversion on Google Code vs. git/mercurial
>> >> on Google Code vs. git at github vs. subversion on Google Code + read
>> >> only git mirror at github vs. subversion on Google Code + read/write
>> >> git mirror at github.  In the end we went with subversion on Google
>> >> Code with possibility of git mirror later because we understand how
>> >> the Maven release process works with subversion and we liked the issue
>> >> tracker at Google Code a lot better than the one at github.
>> >>
>> >>    michael
>> >>
>> >>
>> >> On Thu, Aug 2, 2012 at 11:14 PM,  <[email protected]> wrote:
>> >>> Github ==awesome.
>> >>> Go for it and let the social coding begin
>> >>>
>> >>> Dan
>> >>>
>> >>> Sent from my iPhone
>> >>>
>> >>> On Aug 2, 2012, at 10:11 PM, Hannes Brandstätter-Müller<
[email protected]> wrote:
>> >>>
>> >>>> On Fri, Aug 3, 2012 at 1:52 AM, Andreas Prlic <[email protected]>
wrote:
>> >>>>> Hi,
>> >>>>>
>> >>>>> I was wondering how people feel about migrating the BioJava  svn
>> >>>>> repository and starting to use github for the trunk development?
>> >>>>> (Currently github is only a read-only copy of our developer svn).
>> >>>>>
>> >>>>> Any opinions?
>> >>>>>
>> >>>>> Andreas
>> >>>>
>> >>>> I'm in favor - git pull requests make submitting patches so much
easier, IMHO.
>> >>>>
>> >>>> Hannes
>> >>
>> >> _______________________________________________
>> >> Biojava-l mailing list  -  [email protected]
>> >> http://lists.open-bio.org/mailman/listinfo/biojava-l
>>
>> _______________________________________________
>> Biojava-l mailing list  -  [email protected]
>> http://lists.open-bio.org/mailman/listinfo/biojava-l
>
>

_______________________________________________
Biojava-l mailing list  -  [email protected]
http://lists.open-bio.org/mailman/listinfo/biojava-l