Maybe a more simple perspective.
1.) Fork, Pull and Branch is best for non-commiters and external projects.
IE, if your going to run a local DSpace instance and want to maintain your
customizations in github or if you are working on addons or other fun
things that are not considered "central".
2.) Branch is for DSpace committers who are working on code with the
specific intent of it being in the central master.
Mark
On Fri, Mar 16, 2012 at 7:11 AM, Tim Donohue <[email protected]> wrote:
> Hi Mark,
>
> Yes, you are correct of course. The two approaches are not mutually
> exclusive. But, I do feel we need to develop our own best practices around
> which approach(es) we recommend for which cases.
>
> In other words, if all the Committers are taking different approaches to
> collaboration, then that's not helpful for any of us (and could cause pain
> points in merging together work).
>
> So, at this point, I do feel we should choose a primary collaboration
> model to follow. For example, we may recommend the "Fork & Pull" model for
> the majority of DSpace development (with exceptions for smaller
> tasks/fixes/projects where "Shared Repo"/small branch may be more
> appropriate). Or alternatively, we could recommend the "Shared Repo" model
> for the majority of DSpace development (with exceptions for larger
> tasks/projects/prototypes where "Fork & Pull" may be more appropriate).
>
> - Tim
>
>
> On 3/15/2012 4:58 PM, Mark Diggory wrote:
>
>> Either approach is not mutually exclusive. I believe there are a few
>> orthogonal questions to consider:
>>
>> 1.) Do you want your noise for a prototype spewed out to all the other
>> committers in the central repo, maybe you do / maybe you don't, it
>> depends on the type of project your working on. If you don't want to
>> share all that noise, fork and only send back your prototype when ready.
>>
>> 2.) Do you not want to be concerned with catching up on others changes
>> in the master (i.e. rebasing), (maybe you do, maybe you don't), if you
>> don't want this concern maybe a branch in the central repo is best.
>>
>> 3.) Finally and Possibly most important. How long lived is your branch
>> going to need to be. Is this a short project or a very long project.
>> The Git approach promotes short lived branches, you do your work, prove
>> it works, and merge back to master, throw away the branch. This applies
>> for both cases.
>>
>> Mark
>>
>> --
>> @mire Inc.
>> *Mark Diggory *(Schedule a Meeting
>> <https://www.google.com/**calendar/selfsched?sstoken=**
>> UUdDSzJzTTlOUE1mfGRlZmF1bHR8Mz**gwMmEwYjk1NDc1NDQ1MGI0NWViYjYz**
>> ZjExZDI3Mzg<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg>
>> >)
>> /2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010/
>> /Esperantolaan 4, Heverlee 3001, Belgium/
>> http://www.atmire.com <http://www.atmire.com/>
>>
>>
>>
--
[image: @mire Inc.]
*Mark Diggory *(Schedule a
Meeting<https://www.google.com/calendar/selfsched?sstoken=UUdDSzJzTTlOUE1mfGRlZmF1bHR8MzgwMmEwYjk1NDc1NDQ1MGI0NWViYjYzZjExZDI3Mzg>
)
*2888 Loker Avenue East, Suite 305, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
