[Camps-users] 2 Hackathon branches, need 1 location

Brian J. Miller brian at endpoint.com
Tue Jan 12 16:51:14 UTC 2010


Ethan Rowe wrote:
> Brian J. Miller wrote:
>> Jon Jensen wrote:
>>> On Mon, 11 Jan 2010, Brian J. Miller wrote:
>>>
>>>> While trolling the repo over the weekend I was going to do a bit of work 
>>>> towards 4.x (or whatever you want to call it) and see where I could pick 
>>>> up, unfortunately I picked the wrong branch and ended up blowing some 
>>>> time on fixing unit test files (our Moose needs to be updated, badly) in 
>>>> endpoint_hackathon which appears to be a good deal behind new_hackathon. 
>>>> Neither branch seems overly well named (for the current situation, aka 
>>>> it being nearly a year since the hackathon), so I'd like to propose 
>>>> removing those in the upstream repo and creating a 4_0_0 branch or the 
>>>> like. The name doesn't matter much to me, but I'd like to see us start a 
>>>> convention (not standard) for using branch names with minimally a _X 
>>>> sequence such that when a rebase or the like is required it is easy to 
>>>> see what a branch is working off of. My understanding is that really new 
>>>> work is considered 4.x, hence what I chose, but really I'd be satisfied 
>>>> with devel_X, or if no one likes my other suggestion, how about just 
>>>> devel?
>>>>
>>>> Either way I'd like to get a 4.x line of development going again and 
>>>> have a branch clearly named for that development. Thoughts?
>>> I'd prefer to see it simply named after development somehow, and what's 
>>> wrong with a simple brian_development? If it ends up becoming the 4.0 
>>> branch we can merge it then. Given the number of abortive attempts at a 
>>> 4.0 branch, I'd rather not name anything that till we have code we really 
>>> want to call 4.0.
>>>
>>> Jon
>>>
>> To prevent time wasting trying to determine which branch someone should 
>> start from, like I did over the weekend, but I guess everyone else would 
>> know to check all the active branches to determine which one they like. 
>> Just figured it might help, I had a brian_workup branch which I can 
>> merge/rebase the work from the others into and use, but maintaining 
>> multiple branches that no one knows which will become the "master" seems 
>> less than desirable to me. Someone new to the project (unlikely I know) 
>> wouldn't know whether 'endpoint_hackathon', 'new_hackathon' (whatever 
>> that is...other than the most advanced branch), or 'brian_workup' is the 
>> desired location to do active development not intended for 3.x master. 
>> Perhaps I need to look into a GUI branch grapher so I can see them in a 
>> way my head can wrap. Additionally I'd expect if we are going to have a 
>> bunch of development branches, at some point (actually at various 
>> points) I'd expect us to want to have a central place to merge to so 
>> that work can be shared amongst the branches but ultimately such that 
>> the history is clean (or at least that is what I understood to be the 
>> general attitude).
> 
> Ultimately, I would think we would be best-served by establishing a
> mirror on Github, thus enabling branching to happen at the fork level
> without having to clutter the primary repository with varying lines of
> development.
> 

Not sure I follow the "mirror" thing. The camps repo is already on git 
hub or is there something more specific I'm not following? Either way 
until the new development became master you'd need a branch in the 
github mirror where the development could be shared amongst repos 
(forks) no?

-- 
Brian J. Miller
End Point Corp.
brian at endpoint.com
W: 704-376-8292


More information about the Camps-users mailing list