The writable URL is https://git-wip-us.apache.org/repos/asf/incubator-daffodil.git
John On Wed, Oct 25, 2017 at 9:46 AM John D. Ament <[email protected]> wrote: > You should have access. I believe I created it upon request. > > John > > On Wed, Oct 25, 2017 at 8:07 AM Steve Lawrence <[email protected]> > wrote: > >> It looks like someone has already created an empty repo for us: >> >> https://git-wip-us.apache.org/repos/asf?p=incubator-daffodil.git >> >> And the github mirror: >> >> https://github.com/apache/incubator-daffodil >> >> I haven't tried pushing anything yet so I'm not sure if we have >> permissions. >> >> - Steve >> >> On 10/25/2017 08:04 AM, John D. Ament wrote: >> > All, >> > >> > Do you want to aim to get a repo created on the ASF side? >> > >> > John >> > >> > On Wed, Oct 25, 2017 at 7:10 AM Steve Lawrence <[email protected]> >> wrote: >> > >> >> Yes, branches/tags are essentially renamed. All commit hashes stay the >> >> same. I've made the changes and pushed a test repo to my github: >> >> >> >> https://github.com/stevedlawrence/daffodil-new.git >> >> >> >> If you want to test this, you should be able to add this as a new >> remote >> >> and see the new branch names/tags. >> >> >> >> This renames all version branches to 'support/vN.N.x', all release tags >> >> to 'rel/vN.N.N', and all pre-release tags to 'vN.N.N'. Tags are also >> now >> >> signed in accordance with the tag/branch workflow. >> >> >> >> If this looks good, I can push it to the ASF repo and we can start >> >> transitioning to that + github for the new workflow. >> >> >> >> - Steve >> >> >> >> On 10/25/2017 01:26 AM, Mike Beckerle wrote: >> >>> So branches can just be renamed right? >> >>> >> >>> What I care about is the branches and the commit hashes. If those are >> >> preserved, then the tags don't matter much to me. >> >>> >> >>> >> >>> >> >>> -------- Original message -------- >> >>> From: Steve Lawrence <[email protected]> >> >>> Date: 10/24/17 12:01 PM (GMT-07:00) >> >>> To: [email protected], Mike Beckerle <[email protected]> >> >>> Subject: Re: Import of Code to ASF Infrastructure >> >>> >> >>> The problem is you really can't delete tags in git, so now is really >> the >> >>> best time to do it since we're moving repos. >> >>> >> >>> Is the disruption having to move your local review branches from one >> >>> repo to another? If so, I think I found a decent solution to make a >> >>> clean cut over with just a handful of commands: >> >>> >> >>> Make sure all your changes are committed to a review branch in your >> old >> >>> repo. Move your current repo to a backup location: >> >>> >> >>> $ mv daffodil.git daffodil-ncsa.git >> >>> >> >>> Now clone the ASF git repo that will contain only the new >> tags/branches, >> >>> this will be the new git repo: >> >>> >> >>> $ git clone ${PATH_TO_APCHE_REPO_TBD} daffodil.git >> >>> $ cd daffodil.git >> >>> >> >>> Add your local backup daffodil NCSA repo as a remote, specifying no >> tags >> >>> and all the review branches you want via the -t option. There should >> be >> >>> one -t option for each branch: >> >>> >> >>> $ git remote add --no-tags -t review-sdl-123 -t review-sdl-456 -t >> >>> review-sdl-789 local-daffodil-ncsa ../daffodil-ncsa.git/ >> >>> $ git fetch local-daffodil-ncsa >> >>> >> >>> Create a local branch for each of the fetched review branches: >> >>> >> >>> $ for BRANCH in `git branch -r`; do git branch `echo $BRANCH | cut >> -d/ >> >>> -f2` $BRANCH; done >> >>> >> >>> Now remove the old local-daffodil-ncsa remote: >> >>> >> >>> $ git remote remove local-daffodil-ncsa >> >>> >> >>> You should just be left with all the new tags/branches and your review >> >>> branches. >> >>> >> >>> Does that seem like a reasonable way to cutover without too much >> >>> disruption? I could turn this into a script that will do the cutover >> >>> automatically if that would make things easier? >> >>> >> >>> - Steve >> >>> >> >>> On 10/24/2017 01:19 PM, Mike Beckerle wrote: >> >>>> This will be massively disruptive to me. I have like 7 or 8 >> >> outstanding branches right now. >> >>>> >> >>>> >> >>>> How about we add the new tags and branches and leave the old ones >> there >> >> for now. >> >>>> >> >>>> >> >>>> >> >>>> ________________________________ >> >>>> From: Steve Lawrence <[email protected]> >> >>>> Sent: Tuesday, October 24, 2017 11:48:35 AM >> >>>> To: [email protected] >> >>>> Subject: Import of Code to ASF Infrastructure >> >>>> >> >>>> An issue came up on the Apache Legal bug tracker that has a similar >> >>>> situation to ours. >> >>>> >> >>>> https://issues.apache.org/jira/browse/LEGAL-339 >> >>>> >> >>>> Apache Heron is in a similar stage to us in incubation. They are >> working >> >>>> to transition over to the ASF infrastructure. Their original code is >> >>>> under a permissive license (Apache v2), but they do not have SGAs in >> >>>> place yet, and they wanted to know if they could import their code to >> >>>> ASF. The result of the issue is that since the code is under a >> >>>> permissive license, it is okay to import the code to the ASF git, and >> >>>> just not change any license headers yet. Once the remaining SGAs are >> in >> >>>> place we can change the headers. We can even do releases, but it will >> >>>> prevent graduation, but I suspect we'll have SGAs in place before our >> >>>> first ASF release. >> >>>> >> >>>> Related, I was thinking that if we were to do it, now would be a good >> >>>> time to rename all the old branches and tags to use the new Branch & >> Tag >> >>>> workflow [1] so that all future tags/branch are consistent with the >> old. >> >>>> This would just mean that all rc/alpha tags would have a 'v' >> prepended >> >>>> (e.g. 1.0.0-rc1 -> v1.0.0-rc1), all other tags have 'rel/v' (e.g. >> 1.0.0 >> >>>> -> rel/v1.0.0), and all branches have a 'support/v' prepended and the >> >>>> last digit becomes an 'x' (e.g 1.0.0 -> support/v1.0.x). This won't >> >>>> change what the tags/branches point to, just changes their names. >> >>>> >> >>>> Since this would mean the tags change (which git tends to avoid), >> this >> >>>> will mean that we should all clone the new repo and work out of >> that, no >> >>>> longer using our old clones. This will ensure no old tags stick >> around. >> >>>> For any ongoing work, something like git format-patch would be a good >> >>>> method to get the changes to the new repo. >> >>>> >> >>>> Any thoughts/concerns with this? >> >>>> >> >>>> - Steve >> >>>> >> >>>> >> >>>> [1] >> >>>> >> >> >> https://cwiki.apache.org/confluence/display/DAFFODIL/Branch+and+Tag+Workflow >> >>>> >> >>> >> >>> >> >> >> >> >> > >> >>
