Re: Move to git (Was: Re: httpd 2.4 -> next)

On 2/26/25 5:43 PM, Jim Jagielski wrote:
> 
> 
>> On Feb 10, 2025, at 10:22 AM, Ruediger Pluem <[email protected]> wrote:
>>
>>
>>
>> On 1/29/25 12:48 PM, Jim Jagielski wrote:
>>>
>>>
>>>> On Jan 28, 2025, at 2:21 PM, Ruediger Pluem <[email protected]> wrote:
>>>>
>>>>
>>>>
>>>> On 1/27/25 1:35 PM, Jim Jagielski wrote:
>>>>> Now that we have a release out, which gives us, hopefully, some breathing room, should we migrate over to git in earnest? Or
>>>>> maybe, at least, document a series of tasks required to do so that we _can_ migrate?
>>>>
>>>> Eric already started a confluence page for this:
>>>>
>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=311628229
>>>>
>>>
>>> Thanks! So far the page sez:
>>>
>>>
>>>    Items needed day zero
>>>
>>> 1. ???
>>
>> I added some comments on the page. Some of the points below on the page are IMHO needed by day zero. The release scripts could be
>> developed while we are still on svn in a branch. Hence we would still be able to do a fast release once we switched to git which
>> seems important in case of a need for an emergency release.
>>
> 
> I posted this on the wiki. An alternative might be to move all the support repos "officially" to git, which would allow them to be
> worked on...

I think this is not required in the first place, but we could do this. Although there is currently no branches directory below
https://svn.apache.org/viewvc/httpd/dev-tools/release/ or https://svn.apache.org/viewvc/httpd/dev-tools/ I guess we could create
one and branch the code there. From my point of view this is entirely in the hand of the person who wants to start working on this
and I am fine with either way.

> 
> I am just unsure how much we can do to handle the move to git without the source code actually, canonically, being on git (if you
> get my meaning :) )

Just a quick idea:

1. Branch the current dev-tools (either after moving them to git or on svn) and start switching the code to git.
2. Keep the code easily configurable with regards to the git repo location. This allows to test the scripts against forks of
   https://github.com/apache/httpd where people can do as much "test" release as they want to to test the new scripts without
   the need for the canonical code repository to switch to git before and screwing up something for others. If you screwed up
   the fork you can easily remove it and create a new one.

Regards

Rüdiger