[Camps-users] branches, releases,tags, oh my?

[Brian J. Miller]

David Christensen wrote:
> On Apr 3, 2009, at 11:12 AM, Brian J. Miller wrote:
> 
>> David Christensen wrote:
>>>> 1- Could I request that we tag releases for DevCamps?  That would  
>>>> make
>>>> it easy for people to know they are getting a stable release vs
>>>> something that might be a work in progress.
>>> Makes sense to me.
>>>
>>>> 2- Could I request that no one work directly on the repo?  A recent
>>>> git
>>>> clone of the repo was done while someone had a development branch
>>>> checked out at the repo, and the clone picked up some half-done
>>>> changes.
>>>> It took a little time before we figured out what had occurred and
>>>> reset the branch to the right place on our clone.
>>> Not sure what you mean by "work directly on the repo", but I agree
>>> that we should only push commits which have been peer-reviewed and
>>> generally accepted.  I've thought that an internal development repo
>>> might be useful for blead-camps, with someone to act as a gatekeeper
>>> in pushing thing to the public-facing repo.
>>>
>> Why would this be done with separate repos rather than branches within
>> the repo? Seems like we could setup a blead branch that a developer
>> could track, then a gatekeeper would merge from that branch into  
>> master
>> only when satisfied. Then a user could track master for development,  
>> or
>> tagged master for stable.
> 
> Sure, but AFAIK, there's no way to enforce intra-branch write  
> permissions.  While not strictly necessary, this could prevent  
> accidental commits to the release branch.
> 
> Regards,
> 
> David
> 

If I understand that correctly I'd advocate that that is a social issue
requiring a social solution rather than a technological one, at least
with the limited commit base at this point I don't think it should be a
problem to say...don't do it that way.

-- 
Brian J. Miller
End Point Corp.
brian at endpoint.com