Re: [GRASS-dev] svn/trac -> git/github migration plan
On Sun, May 19, 2019 at 6:53 PM Martin Landa wrote: > Hi, > > ne 19. 5. 2019 v 17:43 odesílatel Markus Metz > Ideally, you would set up the local repo such that you pull from upstream > and push to your fork. > > This is doable with: https://stackoverflow.com/a/4523625/592289 Nevertheless, occasionally, you might want to pull from your personal fork too. E.g. when you want to collaborate on a feature with others. One way to do this is to agree that the development will happen on a branch on your own fork. It doesn't matter if you give write access to the other devs or if they make Pull Requests to your own fork, in the end you will have to pull those changes to your local repo. And in order to do that you will have to again edit your remotes. For the record, in the above example the other devs would have to add your own personal repository as an additional remote. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Sun, May 19, 2019 at 5:53 PM Martin Landa wrote: > ne 19. 5. 2019 v 17:43 odesílatel Markus Metz > napsal: > > For those who do have write access to upstream, it might be safer to have > > origin refer to the personal fork. Ideally, you would set up the local repo > > such that you pull from upstream and push to your fork. > > +1 Ma +1 markusN ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, ne 19. 5. 2019 v 17:43 odesílatel Markus Metz napsal: > For those who do have write access to upstream, it might be safer to have > origin refer to the personal fork. Ideally, you would set up the local repo > such that you pull from upstream and push to your fork. +1 Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Sun, May 19, 2019 at 5:24 PM Vaclav Petras wrote: > > > > On Sat, May 18, 2019 at 12:11 PM Markus Neteler wrote: >> >> >> On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos >> wrote: >> > >> > I would suggest that: >> > >> > - even core devs fork the main repo >> > - "origin" is the personal remote GRASS repository (e.g. in my case https://github.com/pmav99/grass) >> > - everyone adds the main GRASS repository as a secondary remote (e.g. "upstream") >> >> yes, it sounds good to me (while my opinion only counts 0.02 cents here). >> >> > This way: >> > >> > 1. You always push to "origin" and you create a Pull Request from the Github UI >> > 2. To get updates you always pull from "upstream" >> > 3. You always rebase your code to "upstream/master". >> > 4. You don't need separate instructions for non core-devs. >> >> Updated in a similar way to >> >> https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers > > > > Hi, any opinions on what should be the primary and secondary remote? The the fork or upstream? As far as I understood, Bas is suggesting adding the fork, Panos adding the upstream. There does not seem to be that much difference, but the commands are different, so we need to decide for the instructions. GitHub help suggests cloning fork and adding upstream. Syncing to upstream seems more straight forward when cloning upstream and adding to the fork... GDAL [0] suggests to clone upstream, then add your own fork. For those who don't have write access to upstream it does not matter IMHO. For those who do have write access to upstream, it might be safer to have origin refer to the personal fork. Ideally, you would set up the local repo such that you pull from upstream and push to your fork. my 0.2c (trying to learn fast) Markus M [0] https://github.com/OSGeo/gdal/blob/master/CONTRIBUTING.md#initiate-your-work-repository ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Sat, May 18, 2019 at 12:11 PM Markus Neteler wrote: > > On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos > wrote: > > > > I would suggest that: > > > > - even core devs fork the main repo > > - "origin" is the personal remote GRASS repository (e.g. in my case > https://github.com/pmav99/grass) > > - everyone adds the main GRASS repository as a secondary remote (e.g. > "upstream") > > yes, it sounds good to me (while my opinion only counts 0.02 cents here). > > > This way: > > > > 1. You always push to "origin" and you create a Pull Request from the > Github UI > > 2. To get updates you always pull from "upstream" > > 3. You always rebase your code to "upstream/master". > > 4. You don't need separate instructions for non core-devs. > > Updated in a similar way to > > https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers > Hi, any opinions on what should be the primary and secondary remote? The the fork or upstream? As far as I understood, Bas is suggesting adding the fork, Panos adding the upstream. There does not seem to be that much difference, but the commands are different, so we need to decide for the instructions. GitHub help suggests cloning fork and adding upstream. Syncing to upstream seems more straight forward when cloning upstream and adding to the fork... ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Sat, 18 May 2019, 19:11 Markus Neteler, wrote:. > > For fetching the updates, is this enough: > > git pull --all > ? > Μmm... sometimes yes, but I wouldn't suggest it. Git pull is essentially 2 operations in one. It is a git fetch, followed by a git merge. The potential problem is with the merge step. When you have no local changes, git pull works just fine. When you have local changes though, there might be a conflict with the remote ones. And if there is a conflict, you need to resolve it. Resolving the conflicts is not something you can avoid; you will eventually have to do it, but you should probably not try to do it before you have reviewed the (remote) changes you just fetched. This is why I almost always do this in 3 steps: 1. git fetch --all 2. Review the fetched changes. It's often convenient to use a git client here. gitg, qgit and tig are easy to use and lightweight options. 3. git merge By injecting step 2 you can both check if there are any conflicts and think what's the best way to resolve them. Moreover, if there are conflicts, you can choose to postpone resolving them (resolving conflicts takes time). If you do git pull you will have to resolve them straight away. P. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi Panos, all, On Sat, May 18, 2019 at 5:59 PM Panagiotis Mavrogiorgos wrote: > > hello Markus, > > I would suggest that: > > - even core devs fork the main repo > - "origin" is the personal remote GRASS repository (e.g. in my case > https://github.com/pmav99/grass) > - everyone adds the main GRASS repository as a secondary remote (e.g. > "upstream") yes, it sounds good to me (while my opinion only counts 0.02 cents here). > This way: > > 1. You always push to "origin" and you create a Pull Request from the Github > UI > 2. To get updates you always pull from "upstream" > 3. You always rebase your code to "upstream/master". > 4. You don't need separate instructions for non core-devs. Updated in a similar way to https://trac.osgeo.org/grass/wiki/HowToGit#Workflowforcoredevelopers > Just my 2 cents. For fetching the updates, is this enough: git pull --all ? Thanks for your recommendations, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
hello Markus, I would suggest that: - even core devs fork the main repo - "origin" is the personal remote GRASS repository (e.g. in my case https://github.com/pmav99/grass) - everyone adds the main GRASS repository as a secondary remote (e.g. "upstream") This way: 1. You always push to "origin" and you create a Pull Request from the Github UI 2. To get updates you always pull from "upstream" 3. You always rebase your code to "upstream/master". 4. You don't need separate instructions for non core-devs. Just my 2 cents. P. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi devs, please stay tuned for re-enabled write access (for merging), we are working on it. We just have a lot on our plate here during the Berlin sprint (locals and remote participants). cheers, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, On Thu, May 16, 2019 at 3:16 PM Vaclav Petras wrote: > +1 for Markus, Carmen, and Bas. That's what I see used elsewhere too. Great, thanks for the suggestions. I have written up a draft document: https://trac.osgeo.org/grass/wiki/HowToGit Please expand, discuss, ... Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi Panos and all, On Fri, May 17, 2019 at 5:09 AM Panagiotis Mavrogiorgos wrote: > > I would argue that even core developers should not be using the main repo > as their > personal one and that, at least most of the time, they should instead be > using the same > procedure as every other contributor. > Speaking to people here at the Minneapolis sprint this seems to be the preferred way, although not always applied fully. In any case, we should be using this at the beginning to be on the safe side. Then we can evaluate. > > If every core dev starts pushing their personal branches on > the main repo, very soon there will be noise that can effectively become > too much for > UIs to properly display. > This can be mitigated by deleting the branch after merge. There should be a button for that. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Dear all, I would argue that even core developers should not be using the main repo as their personal one and that, at least most of the time, they should instead be using the same procedure as every other contributor. Branches in git branches are really "cheap" (especially compared to e.g. SVN). They do make it very easy to experiment and the more proficient you become with git you do tend to use them more and more. If every core dev starts pushing their personal branches on the main repo, very soon there will be noise that can effectively become too much for UIs to properly display. For example, please visit [QGIS](https://github.com/qgis/QGIS) and click on the branch selector. They only have release branches (like GRASS) and the UI is already at its limit. Imagine having e.g. 100+ more branches there... with kind regards, Panos ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Martin Landa wrote > čt 16. 5. 2019 v 8:25 odesílatel Helmut Kudrnovsky < > hellik@ > > napsal: >> https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git >> >> which file should be updated/checked? > > tools/svn2git/AUTHORS.txt AUTHORS.txt updated in svn to primary gh email - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Thu, May 16, 2019 at 8:26 AM Bas Couwenberg wrote: > > On 2019-05-16 14:16, Markus Neteler wrote: > > External contributors > > # workflow for external contributors - they have to fork the repo in > > GitHub Web interface > > # create fork via github GUI > > git clone $my_for_url > > # all steps see above > > ... > > # push feature branch to own fork repo of GRASS GIS > > git push origin $feature_branch_name # here: origin is fork repo > > # create pull request in GitHub Web interface (the link is shown in > > the terminal) > > May I suggest cloning the grass repo and adding the fork as an > additional remote, this makes merging changes from the grass repo > easier. > ... +1 for Markus, Carmen, and Bas. That's what I see used elsewhere too. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On 2019-05-16 14:16, Markus Neteler wrote: External contributors # workflow for external contributors - they have to fork the repo in GitHub Web interface # create fork via github GUI git clone $my_for_url # all steps see above ... # push feature branch to own fork repo of GRASS GIS git push origin $feature_branch_name # here: origin is fork repo # create pull request in GitHub Web interface (the link is shown in the terminal) May I suggest cloning the grass repo and adding the fork as an additional remote, this makes merging changes from the grass repo easier. git clone https://github.com/OSGeo/grass.git cd grass git remote add github https://github.com//grass.git git remote set-url --push github ssh://g...@github.com//grass.git ... git push github This way origin is the authoritative source for the code, and additional remotes are forks. Kind Regards, Bas ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Thu, May 16, 2019 at 1:30 PM Vaclav Petras wrote: > > > > On Thu, May 16, 2019 at 2:07 AM Martin Landa wrote: >> >> Hi, >> >> st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras >> napsal: >> > Another thing is the need for new contributing guidelines. Git is not >> > Subversion and committing to master won't work ... > > That's the tricky part. The direct commit-push workflow brings issues and > projects tend to avoid it. Agreed. Here two draft workflows, for - core devs, and - external contributors. ### Core developers # workflow for core-developers, no fork needed but using feature branches on master # vim ... # fetch all branches from all remotes git fetch --all # list existing branches: git branch -a # create new local branch (pick a new name for feature_branch_name) git checkout -b $feature_branch_name # list local changes git status git add file1.c file2.py ... git commit -m 'my change with reasonable explanation...' # push feature branch to origin, i.e. original GRASS GIS repo master git push origin $feature_branch_name # create pull request in GitHub Web interface (the link is shown in the terminal) # during PR review phase, make more local changes if needed git add . git commit -m 'my second change' git push origin $feature_branch_name # . will be added to existing pull request # NOTE: for different pull requests, simply create different feature branches. External contributors # workflow for external contributors - they have to fork the repo in GitHub Web interface # create fork via github GUI git clone $my_for_url # all steps see above ... # push feature branch to own fork repo of GRASS GIS git push origin $feature_branch_name # here: origin is fork repo # create pull request in GitHub Web interface (the link is shown in the terminal) Certainly we need to write this up in a Wiki page. Thanks to Carmen Tawalika for drafting the workflow. Best, Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Thu, May 16, 2019 at 2:07 AM Martin Landa wrote: > Hi, > > st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras > napsal: > > Another thing is the need for new contributing guidelines. Git is not > Subversion and committing to master won't work (please, let me know if you > want me to show some examples). What other OSGeo projects are doing is that > contributing guidelines say that you should do pull request. It seems that > this is often preferred way even for core developers. From what I gathered > from a small sample of people at OSGeo sprint, the core devs don't go > though fork, but they do go through a branch. In GitHub, we can set > "Require pull request reviews before merging" and "Include administrators" > for the master branch to enforce that. I think we should do it at least at > the beginning. > > I tend to agree. Contributes with a write access should do PR for > massive/tricky changes. It's perfect platform to discuss/improve > changes before merging. Trivial changes can be committed/pushed > directly, no PR needed. > That's the tricky part. The direct commit-push workflow brings issues and projects tend to avoid it. The most direct access is (usually?) going through a branch in a main repo and merging that (merging through GitHub PR). The point of PR is not only discussion but also testing. The CI should run for every commit (chunk of commits in PR to be exact) before it goes into master. Additionally, it there are simply no trivial changes. Even a change in documentation page can introduce an HTML tag not recognized by g.html2man causing compilation to fail. Similarly, with asynchronous commits you are at risk of conflicts and always in need of merge and the question is how you want this to be recorded in code history. With Subversion, each developer needs to resolve that before commit individually. With Git, you can have history with locally created automatic merge commits, you need do git pull --rebase locally, or you need to do PRs*. I'm not saying this because I particularly like that, but because that's how Git/GitHub** is used and that's what we are signing up for. * PRs are called merge requests in GitLab; perhaps hinting more on what they are for. ** This is not limited to GitHub, for example, GitLab by default locks master when you create a new repo. Vaclav ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, Being no developer by education I can only second this! Guidelines and simple, minimal example workflows would be very, very welcome (we learned fork->branch->commit->pull request (and then?, how do I keep my fork in sync, ...) ! I also agree that we should be vary of duplicating git documentation but rather have minimal description of recommended workflows, starting with the most common cases (which of course can evolve over time) and point to more lengthy explanations other places. Just like: https://trac.osgeo.org/grass/wiki/HowToSVN#SVNusage git also has some pitfalls people should be aware of, like e.g. handling of line endings: https://help.github.com/en/articles/dealing-with-line-endings These can be pretty annoying, but circumvented if taken into account early on... And then there are some more possible git adjustments (in the codebase), like proper markdown formating of the README as well as probably some stuff from here: https://github.com/grass-svn2git/grass/community (yes, I am aware that this is not the final repo) Thanks for the massive work, Martin (and others involved). Looking forward to GRASS on git! Cheers Stefan Currently, I am struggling in another project with line endings which makes contributions across plattforms complicated... -Original Message- From: grass-dev On Behalf Of Luca Delucchi Sent: onsdag 15. mai 2019 22:21 To: Veronica Andreo Cc: Martin Landa ; grass-dev Subject: Re: [GRASS-dev] svn/trac -> git/github migration plan On Wed, 15 May 2019 at 21:40, Veronica Andreo wrote: > > Hi, > Hi, >> Another thing is the need for new contributing guidelines. Git is not >> Subversion and committing to master won't work (please, let me know if you >> want me to show some examples). > > > I am very interested in such examples, esp. how the workflow will be from now > on for example when making a small change in manuals. > Yes, it is important to know this. How to use branches and also how to update local version from the master one. Should we use a private clone and make pull request to the main repository o use the main repository directly? > I think it is very important that those of you more familiar with git and > GitHub develop or show example workflows of how to contribute, backport (if > that will be still called like that), and so on. > +1 > my 0.01 cent > Vero > -- ciao Luca www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
čt 16. 5. 2019 v 8:25 odesílatel Helmut Kudrnovsky napsal: > https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git > > which file should be updated/checked? tools/svn2git/AUTHORS.txt Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Martin Landa wrote > Hi, > > st 15. 5. 2019 v 21:32 odesílatel Helmut Kudrnovsky < > hellik@ > > napsal: >> svn: hellik >> >> gh account: hellik >> email: > hkmyricaria@ > > in the case you have write access to Addons, you can directly modify > the file :-) Thanks, Ma I have write access :-). https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git which file should be updated/checked? - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, st 15. 5. 2019 v 21:32 odesílatel Helmut Kudrnovsky napsal: > svn: hellik > > gh account: hellik > email: hkmyrica...@gmail.com in the case you have write access to Addons, you can directly modify the file :-) Thanks, Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, st 15. 5. 2019 v 18:47 odesílatel Markus Neteler napsal: > This are the authors who have a GitHub account known to us. There is a lookup > table which maps SVN account to GitHub account (in addons/tools/svn2git > somewhere). http://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git/AUTHORS.txt Please check if you are on the list. This list contains all contributors including Addons! Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, st 15. 5. 2019 v 18:20 odesílatel Vaclav Petras napsal: > Another thing is the need for new contributing guidelines. Git is not > Subversion and committing to master won't work (please, let me know if you > want me to show some examples). What other OSGeo projects are doing is that > contributing guidelines say that you should do pull request. It seems that > this is often preferred way even for core developers. From what I gathered > from a small sample of people at OSGeo sprint, the core devs don't go though > fork, but they do go through a branch. In GitHub, we can set "Require pull > request reviews before merging" and "Include administrators" for the master > branch to enforce that. I think we should do it at least at the beginning. I tend to agree. Contributes with a write access should do PR for massive/tricky changes. It's perfect platform to discuss/improve changes before merging. Trivial changes can be committed/pushed directly, no PR needed. +1 my cent Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, May 15, 2019 at 4:24 PM Markus Neteler wrote: > > On Wed, May 15, 2019 at 10:20 PM Luca Delucchi wrote: > > On Wed, 15 May 2019 at 21:40, Veronica Andreo wrote: > > >> Another thing is the need for new contributing guidelines. Git is not Subversion and committing to master won't work (please, let me know if you want me to show some examples). > > > > > > I am very interested in such examples, esp. how the workflow will be from now on for example when making a small change in manuals. > > > > Yes, it is important to know this. How to use branches and also how to > > update local version from the master one. Should we use a private > > clone and make pull request to the main repository o use the main > > repository directly? > > AFAIK it is recommended to open an own "feature branch" in the own > fork and then open a pull request. Exactly. The important part to recognize is that trying to emulate the Subversion workflow, i.e. simply committing to master, would soon turn into a repo full of automatic merge commits in the best case and big confusion in the worst case. Basically all projects (I think I checked QGIS, PROJ, GDAL, PDAL) have fork+branch+pull request as their best practice. This means that even if you are a core developer, you still should do that. The exception common for the core developers is that they skip the fork part, i.e. they branch in the main repo. However, I haven't seen that formalized, so I think it is a tolerated practice rather than a guideline. Hopefully, for the general case, GRASS GIS will not need any special instructions. Often projects simply point to GitHub documentation for making and maintaining a fork and making a pull request. Although there will be extra steps for the people with direct access to source code comparing to Subversion, the benefit is that there is (will be) actually an extra step and that's CI build and (hopefully) test as well. This should catch many issues before they get to master. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Markus Neteler wrote > On Wed, May 15, 2019 at 9:32 PM Helmut Kudrnovsky < > hellik@ > > wrote: >> >> Markus Neteler wrote >> > So, if someone isn't listed yet: >> > Please get a GitHub account and/or communicate it to us (name + related >> > email). >> >> svn: hellik >> >> gh account: hellik > > You were already in the list. > > But: > >> email: > hkmyricaria@ > > Your > hellik@ > is apparently not yet registered at Github. > Solution: > > Or, simply, to match your commits to your GitHub account, just add > your associated email address(es) to your account in order to claim > your contributions (https://github.com/settings/emails). > > Then you should show up there after some minutes or so. additional email in my github account added, so lets see - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, May 15, 2019 at 10:20 PM Luca Delucchi wrote: > On Wed, 15 May 2019 at 21:40, Veronica Andreo wrote: > >> Another thing is the need for new contributing guidelines. Git is not > >> Subversion and committing to master won't work (please, let me know if you > >> want me to show some examples). > > > > I am very interested in such examples, esp. how the workflow will be from > > now on for example when making a small change in manuals. > > Yes, it is important to know this. How to use branches and also how to > update local version from the master one. Should we use a private > clone and make pull request to the main repository o use the main > repository directly? AFAIK it is recommended to open an own "feature branch" in the own fork and then open a pull request. Concerning backports we could check the bot magic used by other OSGeo projects. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, 15 May 2019 at 21:40, Veronica Andreo wrote: > > Hi, > Hi, >> Another thing is the need for new contributing guidelines. Git is not >> Subversion and committing to master won't work (please, let me know if you >> want me to show some examples). > > > I am very interested in such examples, esp. how the workflow will be from now > on for example when making a small change in manuals. > Yes, it is important to know this. How to use branches and also how to update local version from the master one. Should we use a private clone and make pull request to the main repository o use the main repository directly? > I think it is very important that those of you more familiar with git and > GitHub develop or show example workflows of how to contribute, backport (if > that will be still called like that), and so on. > +1 > my 0.01 cent > Vero > -- ciao Luca www.lucadelu.org ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, May 15, 2019 at 9:32 PM Helmut Kudrnovsky wrote: > > Markus Neteler wrote > > So, if someone isn't listed yet: > > Please get a GitHub account and/or communicate it to us (name + related > > email). > > svn: hellik > > gh account: hellik You were already in the list. But: > email: hkmyrica...@gmail.com Your hel...@web.de is apparently not yet registered at Github. Solution: Or, simply, to match your commits to your GitHub account, just add your associated email address(es) to your account in order to claim your contributions (https://github.com/settings/emails). Then you should show up there after some minutes or so. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, May 15, 2019 at 9:27 PM Vaclav Petras wrote: > On Wed, May 15, 2019 at 12:47 PM Markus Neteler wrote: >> Later on, also commit claiming is possible and easy, so nothing is lost. > > Sounds good. I didn't know. We just have to be very clear about the current > state not capturing everyone. So I wrote this section just now: https://trac.osgeo.org/grass/wiki/GitMigration#Authorship:RecognizingtheGRASSGIScontributorsduringandaftermigration Feel free to improve the wording. Markus -- Markus Neteler, PhD https://www.mundialis.de - free data with free software https://grass.osgeo.org https://courses.neteler.org/blog ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, El mié., 15 may. 2019 13:20, Vaclav Petras escribió: > > > On Wed, May 15, 2019 at 9:14 AM Martin Landa > wrote: > >> Hi, >> >> st 15. 5. 2019 v 9:51 odesílatel Martin Landa >> napsal: >> > Something strange happen with svn repo after r74441. I will publish >> > testing repo for public review hopefully today. >> >> OK, finally a new fresh grass repo preview available for review (last >> processed commit 74475). >> >> Please compare git content [1], branches [2] and tags [3] with svn. >> Please review logs reporting changed message [4] and unchanged >> messages [5]. > > > I was also looking at the list of contributors [6]. I know this was > discussed, but now I'm not really sure what to expect there. > > [6] https://github.com/grass-svn2git/grass/graphs/contributors > > >> If no problems appears this will be the last >> preview before REAL migration. >> > > When comparing the content of the repositories, I see the difference in > $Date$ which of course has the whole system related to it. What we are > doing with that? > > Another thing is the need for new contributing guidelines. Git is not > Subversion and committing to master won't work (please, let me know if you > want me to show some examples). > I am very interested in such examples, esp. how the workflow will be from now on for example when making a small change in manuals. I think it is very important that those of you more familiar with git and GitHub develop or show example workflows of how to contribute, backport (if that will be still called like that), and so on. my 0.01 cent Vero What other OSGeo projects are doing is that contributing guidelines say > that you should do pull request. It seems that this is often preferred way > even for core developers. From what I gathered from a small sample of > people at OSGeo sprint, the core devs don't go though fork, but they do go > through a branch. In GitHub, we can set "Require pull request reviews > before merging" and "Include administrators" for the master branch to > enforce that. I think we should do it at least at the beginning. > > Vaclav > > >> >> [1] https://github.com/grass-svn2git/grass >> [2] https://github.com/grass-svn2git/grass >> [3] https://github.com/grass-svn2git/grass/releases >> [4] http://geo102.fsv.cvut.cz/~landa/tmp/log_grass_touched.txt >> [5] http://geo102.fsv.cvut.cz/~landa/tmp/log_grass_untouched.txt >> >> -- >> Martin Landa >> http://geo.fsv.cvut.cz/gwiki/Landa >> http://gismentors.cz/mentors/landa >> ___ >> grass-dev mailing list >> grass-dev@lists.osgeo.org >> https://lists.osgeo.org/mailman/listinfo/grass-dev > > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Markus Neteler wrote > So, if someone isn't listed yet: > Please get a GitHub account and/or communicate it to us (name + related > email). svn: hellik gh account: hellik email: hkmyrica...@gmail.com - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, May 15, 2019 at 12:47 PM Markus Neteler wrote: > > Later on, also commit claiming is possible and easy, so nothing is lost. > Sounds good. I didn't know. We just have to be very clear about the current state not capturing everyone. ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, a quick comment on this one: Vaclav Petras schrieb am Mi., 15. Mai 2019, 18:20: > > ... > I was also looking at the list of contributors [6]. I know this was > discussed, but now I'm not really sure what to expect there. > > [6] https://github.com/grass-svn2git/grass/graphs/contributors > This are the authors who have a GitHub account known to us. There is a lookup table which maps SVN account to GitHub account (in addons/tools/svn2git somewhere). In fact, the list is currently a tiny fraction of the real authorship! So, if someone isn't listed yet: Please get a GitHub account and/or communicate it to us (name + related email). Later on, also commit claiming is possible and easy, so nothing is lost. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Wed, May 15, 2019 at 9:14 AM Martin Landa wrote: > Hi, > > st 15. 5. 2019 v 9:51 odesílatel Martin Landa > napsal: > > Something strange happen with svn repo after r74441. I will publish > > testing repo for public review hopefully today. > > OK, finally a new fresh grass repo preview available for review (last > processed commit 74475). > > Please compare git content [1], branches [2] and tags [3] with svn. > Please review logs reporting changed message [4] and unchanged > messages [5]. I was also looking at the list of contributors [6]. I know this was discussed, but now I'm not really sure what to expect there. [6] https://github.com/grass-svn2git/grass/graphs/contributors > If no problems appears this will be the last > preview before REAL migration. > When comparing the content of the repositories, I see the difference in $Date$ which of course has the whole system related to it. What we are doing with that? Another thing is the need for new contributing guidelines. Git is not Subversion and committing to master won't work (please, let me know if you want me to show some examples). What other OSGeo projects are doing is that contributing guidelines say that you should do pull request. It seems that this is often preferred way even for core developers. From what I gathered from a small sample of people at OSGeo sprint, the core devs don't go though fork, but they do go through a branch. In GitHub, we can set "Require pull request reviews before merging" and "Include administrators" for the master branch to enforce that. I think we should do it at least at the beginning. Vaclav > > [1] https://github.com/grass-svn2git/grass > [2] https://github.com/grass-svn2git/grass > [3] https://github.com/grass-svn2git/grass/releases > [4] http://geo102.fsv.cvut.cz/~landa/tmp/log_grass_touched.txt > [5] http://geo102.fsv.cvut.cz/~landa/tmp/log_grass_untouched.txt > > -- > Martin Landa > http://geo.fsv.cvut.cz/gwiki/Landa > http://gismentors.cz/mentors/landa > ___ > grass-dev mailing list > grass-dev@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/grass-dev ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
> [2] https://github.com/grass-svn2git/grass [2] https://github.com/grass-svn2git/grass/branches/all -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, st 15. 5. 2019 v 9:51 odesílatel Martin Landa napsal: > Something strange happen with svn repo after r74441. I will publish > testing repo for public review hopefully today. OK, finally a new fresh grass repo preview available for review (last processed commit 74475). Please compare git content [1], branches [2] and tags [3] with svn. Please review logs reporting changed message [4] and unchanged messages [5]. Thanks! If no problems appears this will be the last preview before REAL migration. Ma [1] https://github.com/grass-svn2git/grass [2] https://github.com/grass-svn2git/grass [3] https://github.com/grass-svn2git/grass/releases [4] http://geo102.fsv.cvut.cz/~landa/tmp/log_grass_touched.txt [5] http://geo102.fsv.cvut.cz/~landa/tmp/log_grass_untouched.txt -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 13. 5. 2019 v 15:32 odesílatel Martin Landa napsal: > unfortunately attempt to run `git svn fetch` incrementally fails with > similar error: > > $ git svn -r74443:75000 --authors-file=../AUTHORS.txt fetch > Error from SVN, (160006): Invalid filesystem revision number: No such > revision 74543 I tried to run `0-migrate-fetch.sh` directly on svn osgeo server. Fetching over `file://` fails with the same error. Strangely when fetching over `http://` the command is somehow able to recover: ... r74441 = 9f7eef32fec5f0e898e794854591b9015afed26d (refs/remotes/trunk) Mraster/r.thin/thin_lines.c r74442 = 13e9f72398b8e3db69dd5f2c567553f6d46878b5 (refs/remotes/trunk) W: Ignoring error from SVN, path probably does not exist: (175002): RA layer request failed: Unexpected HTTP status 500 'Internal Server Error' on '/grass/!svn/rvr/74542' : Additional errors:: No such revision 74542 W: Do not be alarmed at the above message git-svn is just searching aggressively for old history. This may take a while on large repositories Path 'grass' was probably deleted: RA layer request failed: Unexpected HTTP status 500 'Internal Server Error' on '/grass/!svn/rvr/74542' : Additional errors:: No such revision 74542 Will attempt to follow revisions r74443 .. r74542 committed before the deletion r74443 .. r74476 OK Mraster/r.thin/thin_lines.c r74443 = 4e76c156c6b0b547e30a3399642074d82f5729bf (refs/remotes/releasebranch_7_6) Mraster/r.thin/local_proto.h Mraster/r.thin/thin_lines.c ... Something strange happen with svn repo after r74441. I will publish testing repo for public review hopefully today. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
po 13. 5. 2019 v 15:24 odesílatel Martin Landa napsal: unfortunately attempt to run `git svn fetch` incrementally fails with similar error: $ git svn -r74443:75000 --authors-file=../AUTHORS.txt fetch Error from SVN, (160006): Invalid filesystem revision number: No such revision 74543 Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
po 13. 5. 2019 v 15:01 odesílatel Martin Landa napsal: r74440 = 1f1209cbe0074f1e6451b4ed40f56a22192724e7 (refs/remotes/origin/trunk) Mraster/r.to.vect/areas_io.c Mraster/r.to.vect/lines.c Mraster/r.to.vect/lines_io.c r74441 = 2fb78d92ee0ad2570a4388b30aeb3cdc63326cdb (refs/remotes/origin/trunk) Mraster/r.thin/thin_lines.c r74442 = a3741bbbdfc31118ea9ab9d98a6bd15a39b6fa83 (refs/remotes/origin/trunk) Error from SVN, (160006): Invalid filesystem revision number: No such revision 74542 it seems that it fails to grab r74442 when it starts to speak surprisingly about non-existing. But this works: $ svn log file:///opt/osgeo/svn/repos/grass/grass ... r74443 | mmetz | 2019-04-30 20:28:34 +0200 (Tue, 30 Apr 2019) | 1 line r.thin: avoid integer overflow, remove unused variable (backport trunk r74442) r74442 | mmetz | 2019-04-30 20:26:10 +0200 (Tue, 30 Apr 2019) | 1 line r.thin: avoid integer overflow, remove unused variable ... I run `git svn fetch` many times when doing various tests. I have no idea what could be wrong at this moment. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 13. 5. 2019 v 14:58 odesílatel Martin Landa napsal: > > https://trac.osgeo.org/grass/changeset/74542 > > Error: Invalid Changeset Number > > NoSuchChangeset: No changeset 74542 in the repository > > > > ... but that number is nonsense, as it was not reached yet. > > yes, this error comes from `git svn fetch`. No idea why it dreams > about non existing revision. Ma I am getting the same error when using locally dumped svn repo (till now I was using just tarball). We have a new blocker. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 13. 5. 2019 v 14:11 odesílatel Markus Neteler napsal: > > r74442 = a3741bbbdfc31118ea9ab9d98a6bd15a39b6fa83 > > (refs/remotes/origin/trunk) > > Error from SVN, (160006): Invalid filesystem revision number: No such > > revision 74542 > > In fact, not there: > > https://trac.osgeo.org/grass/changeset/74542 > Error: Invalid Changeset Number > NoSuchChangeset: No changeset 74542 in the repository > > ... but that number is nonsense, as it was not reached yet. yes, this error comes from `git svn fetch`. No idea why it dreams about non existing revision. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Mon, May 13, 2019 at 1:31 PM Martin Landa wrote: > > Hi, > > po 13. 5. 2019 v 13:21 odesílatel Moritz Lennert > napsal: > > I think we just need to get the ball rolling. There will certainly be > > some transition pain, but if we try to prepare everything to perfection > > it will never happen ;-) > > right, currently I am working on source code migration. Unfortunately > there is a new issue which is quite pain. My last attempt to create > git repo from fresh svn [1] copy (tarball) fails with > > r74442 = a3741bbbdfc31118ea9ab9d98a6bd15a39b6fa83 (refs/remotes/origin/trunk) > Error from SVN, (160006): Invalid filesystem revision number: No such > revision 74542 In fact, not there: https://trac.osgeo.org/grass/changeset/74542 Error: Invalid Changeset Number NoSuchChangeset: No changeset 74542 in the repository ... but that number is nonsense, as it was not reached yet. --> r74478 this changeset is the highest number at time: https://trac.osgeo.org/grass/changeset/74478 [mneteler@oboe grass77 ]$ svn up Updating '.': At revision 74478. [mneteler@oboe grass77 ]$ date -u Mon 13 May 2019 12:09:58 PM UTC Maybe easy to solve? Or am I overlooking anything? Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 13. 5. 2019 v 13:21 odesílatel Moritz Lennert napsal: > I think we just need to get the ball rolling. There will certainly be > some transition pain, but if we try to prepare everything to perfection > it will never happen ;-) right, currently I am working on source code migration. Unfortunately there is a new issue which is quite pain. My last attempt to create git repo from fresh svn [1] copy (tarball) fails with r74442 = a3741bbbdfc31118ea9ab9d98a6bd15a39b6fa83 (refs/remotes/origin/trunk) Error from SVN, (160006): Invalid filesystem revision number: No such revision 74542 Now retrying with svn dump. When it will be solved I will publish links to rewritten messages log and new git repo for public review. Ma [1] https://trac.osgeo.org/grass/browser/grass-addons/tools/svn2git/0-migrate-fetch.sh#L17 -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On 12/05/19 18:19, Markus Neteler wrote: On Fri, May 10, 2019 at 5:06 PM Martin Landa wrote: Hi, út 7. 5. 2019 v 10:26 odesílatel Martin Landa napsal: commits can be referenced to github issues. Issue migration needs to be also done on private repository. This would require to set up empty private repo, migrate tickets and than transfer ticket using GitHub API to public repo. This complicates procedure a bit. I would still prefer to do source code and issues migration together even it will take some time. back to this topic, I added to trac an alternative scenario based on two steps (source code and issues migration separated) [1]. Opinions welcome. We are very close to day D. Excellent. IMHO the separate migration of source code and issues is the way to go. Like that we can already work with the then completed migration next weekend in Berlin and define workflows. +1 I think we just need to get the ball rolling. There will certainly be some transition pain, but if we try to prepare everything to perfection it will never happen ;-) Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Fri, May 10, 2019 at 5:06 PM Martin Landa wrote: > > Hi, > > út 7. 5. 2019 v 10:26 odesílatel Martin Landa napsal: > > commits can be referenced to github issues. Issue migration needs to > > be also done on private repository. This would require to set up empty > > private repo, migrate tickets and than transfer ticket using GitHub > > API to public repo. This complicates procedure a bit. I would still > > prefer to do source code and issues migration together even it will > > take some time. > > back to this topic, I added to trac an alternative scenario based on > two steps (source code and issues migration separated) [1]. Opinions > welcome. We are very close to day D. Excellent. IMHO the separate migration of source code and issues is the way to go. Like that we can already work with the then completed migration next weekend in Berlin and define workflows. Issue migration can follow then. Best, Markus > Ma > > [1] https://trac.osgeo.org/grass/wiki/GitMigration#Scenario2twosteps ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Fri, May 10, 2019 at 4:03 PM Helmut Kudrnovsky wrote: > Markus Neteler wrote > > On Fri, May 10, 2019 at 1:12 PM Helmut Kudrnovsky < > >> so far I couldn't find a solution for the winGRASS trunk regression > > > > The only way I see is to revert the change and see if it works again. > > If yes, break this big commit into chunks and try further. > > as there were many encoding related commits in the last time, anyone any > idea where to start? https://trac.osgeo.org/grass/ticket/3790#comment:6 This was the big commit: https://trac.osgeo.org/grass/changeset/74307 Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, út 7. 5. 2019 v 10:26 odesílatel Martin Landa napsal: > commits can be referenced to github issues. Issue migration needs to > be also done on private repository. This would require to set up empty > private repo, migrate tickets and than transfer ticket using GitHub > API to public repo. This complicates procedure a bit. I would still > prefer to do source code and issues migration together even it will > take some time. back to this topic, I added to trac an alternative scenario based on two steps (source code and issues migration separated) [1]. Opinions welcome. We are very close to day D. Ma [1] https://trac.osgeo.org/grass/wiki/GitMigration#Scenario2twosteps -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Markus Neteler wrote > On Fri, May 10, 2019 at 1:12 PM Helmut Kudrnovsky < > hellik@ > > wrote: > ... >> so far I couldn't find a solution for the winGRASS trunk regression > > The only way I see is to revert the change and see if it works again. > If yes, break this big commit into chunks and try further. > > Markus > ___ > grass-dev mailing list > grass-dev@.osgeo > https://lists.osgeo.org/mailman/listinfo/grass-dev as there were many encoding related commits in the last time, anyone any idea where to start? - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
On Fri, May 10, 2019 at 1:12 PM Helmut Kudrnovsky wrote: ... > so far I couldn't find a solution for the winGRASS trunk regression The only way I see is to revert the change and see if it works again. If yes, break this big commit into chunks and try further. Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi Vero, >See Martin's original mail and links. The tickets that need to be >reviewed are those with milestone 7.0.7 and 7.2.4, as to know if >they are still valid and milestone should be moved to 7.6.2 IMHO when I go through the tickets for 7.0.7 and 7.2.4, an additional check with trunk (Python 3) could be done at the same time and may save resources later on to decide if a fix should go to 7.6 /7.8 or maybe only to 7.8 cause of a different code base (py2 vs py3) and/or focus on 7.8 only so far I couldn't find a solution for the winGRASS trunk regression - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi Helli El jue., 9 may. 2019 19:53, Helmut Kudrnovsky escribió: > Veronica Andreo wrote > > Hola :) > > > > El mar., 7 may. 2019 a las 16:20, Veronica Andreo (< > > > veroandreo@ > > > >) > > escribió: > > > >> El mar., 7 may. 2019 a las 11:54, Martin Landa (< > > > landa.martin@ > > > >) > >> escribió: > >> > >>> Hi, > >>> > >>> út 7. 5. 2019 v 11:14 odesílatel Veronica Andreo < > > > veroandreo@ > > > > > >>> napsal: > >>> > I'd suggest then to set a deadline for ticket review by reporters, > eg: > >>> this Sunday (or any other date before the planned code sprint in > Berlin) > >>> > >>> could work. Till Sunday I will have also time to test issue migration > >>> a bit more. Then migration could happen in beginning of next week > >>> (Mon/Tue). > >>> > >> > > Any other opinion/objection? Shall I post on FB and Twitter then? New > > announcement here with deadline? > > > > Vero > > > >> > >> +1! :) > >> > >> Vero > >> > > > > ___ > > grass-dev mailing list > > > grass-dev@.osgeo > > > https://lists.osgeo.org/mailman/listinfo/grass-dev > > at least regarding tickets related to winGRASS 7.7.svn/Trunk and Python 3, > trac issues can't be reviewed cause of > > https://trac.osgeo.org/grass/ticket/3837 See Martin's original mail and links. The tickets that need to be reviewed are those with milestone 7.0.7 and 7.2.4, as to know if they are still valid and milestone should be moved to 7.6.2 Tickets with milestone 7.8 will be migrated anyway... Vero > > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Veronica Andreo wrote > Hola :) > > El mar., 7 may. 2019 a las 16:20, Veronica Andreo (< > veroandreo@ > >) > escribió: > >> El mar., 7 may. 2019 a las 11:54, Martin Landa (< > landa.martin@ > >) >> escribió: >> >>> Hi, >>> >>> út 7. 5. 2019 v 11:14 odesílatel Veronica Andreo < > veroandreo@ > > >>> napsal: >>> > I'd suggest then to set a deadline for ticket review by reporters, eg: >>> this Sunday (or any other date before the planned code sprint in Berlin) >>> >>> could work. Till Sunday I will have also time to test issue migration >>> a bit more. Then migration could happen in beginning of next week >>> (Mon/Tue). >>> >> > Any other opinion/objection? Shall I post on FB and Twitter then? New > announcement here with deadline? > > Vero > >> >> +1! :) >> >> Vero >> > > ___ > grass-dev mailing list > grass-dev@.osgeo > https://lists.osgeo.org/mailman/listinfo/grass-dev at least regarding tickets related to winGRASS 7.7.svn/Trunk and Python 3, trac issues can't be reviewed cause of https://trac.osgeo.org/grass/ticket/3837 - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hola :) El mar., 7 may. 2019 a las 16:20, Veronica Andreo () escribió: > El mar., 7 may. 2019 a las 11:54, Martin Landa () > escribió: > >> Hi, >> >> út 7. 5. 2019 v 11:14 odesílatel Veronica Andreo >> napsal: >> > I'd suggest then to set a deadline for ticket review by reporters, eg: >> this Sunday (or any other date before the planned code sprint in Berlin) >> >> could work. Till Sunday I will have also time to test issue migration >> a bit more. Then migration could happen in beginning of next week >> (Mon/Tue). >> > Any other opinion/objection? Shall I post on FB and Twitter then? New announcement here with deadline? Vero > > +1! :) > > Vero > ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
El mar., 7 may. 2019 a las 11:54, Martin Landa () escribió: > Hi, > > út 7. 5. 2019 v 11:14 odesílatel Veronica Andreo > napsal: > > I'd suggest then to set a deadline for ticket review by reporters, eg: > this Sunday (or any other date before the planned code sprint in Berlin) > > could work. Till Sunday I will have also time to test issue migration > a bit more. Then migration could happen in beginning of next week > (Mon/Tue). > +1! :) Vero ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, út 7. 5. 2019 v 11:14 odesílatel Veronica Andreo napsal: > I'd suggest then to set a deadline for ticket review by reporters, eg: this > Sunday (or any other date before the planned code sprint in Berlin) could work. Till Sunday I will have also time to test issue migration a bit more. Then migration could happen in beginning of next week (Mon/Tue). Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi Martin, Thanks for explanation and for all your hard work! :) El mar., 7 may. 2019 05:28, Martin Landa escribió: > Hi, > > po 6. 5. 2019 v 23:06 odesílatel Veronica Andreo > napsal: > > Say, if source code migration starts tomorrow, how long it would take? > Then set that day (+2 or 3 if you want) as deadline for tickets revision, > then migrate tickets, done :) > > source code migration will take a few hours. See my notes in previous > mail. I'd suggest then to set a deadline for ticket review by reporters, eg: this Sunday (or any other date before the planned code sprint in Berlin) Vero ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 6. 5. 2019 v 23:06 odesílatel Veronica Andreo napsal: > Say, if source code migration starts tomorrow, how long it would take? Then > set that day (+2 or 3 if you want) as deadline for tickets revision, then > migrate tickets, done :) source code migration will take a few hours. See my notes in previous mail. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 6. 5. 2019 v 22:49 odesílatel Markus Neteler napsal: > Why wait for that with the source code migration? > Please let's start with it. The tickets can follow in a second step. > This also prevents us from being overloaded. my idea to do migration in one step comes from assumption that new git commits can be referenced to github issues. Issue migration needs to be also done on private repository. This would require to set up empty private repo, migrate tickets and than transfer ticket using GitHub API to public repo. This complicates procedure a bit. I would still prefer to do source code and issues migration together even it will take some time. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, El lun., 6 may. 2019 17:49, Markus Neteler escribió: > Hi Martin, > > On Mon, May 6, 2019 at 11:41 AM Martin Landa > wrote: > > > > Dear all, > > > > based on decision made by PSC [1], the GRASS GIS source code will be > > moved from SVN hosted by OSGeo to Git hosted by GitHub.com. More > > details at [2]. > > [...migration of tickets ...] > > > When this part will be done the migration can start, see draft [5]. > > Why wait for that with the source code migration? > Please let's start with it. The tickets can follow in a second step. > +1! Say, if source code migration starts tomorrow, how long it would take? Then set that day (+2 or 3 if you want) as deadline for tickets revision, then migrate tickets, done :) My 0.01 pesos cents :D Vero ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi Martin, On Mon, May 6, 2019 at 11:41 AM Martin Landa wrote: > > Dear all, > > based on decision made by PSC [1], the GRASS GIS source code will be > moved from SVN hosted by OSGeo to Git hosted by GitHub.com. More > details at [2]. [...migration of tickets ...] > When this part will be done the migration can start, see draft [5]. Why wait for that with the source code migration? Please let's start with it. The tickets can follow in a second step. This also prevents us from being overloaded. My 0.02 cents, Markus > [1] https://lists.osgeo.org/pipermail/grass-psc/2019-April/002034.html > [2] > https://trac.osgeo.org/grass/wiki/GitMigration#ImplementationofmigrationfromOSGeoSVNandtractoGitHub > [3] > https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=status&milestone=7.0.7 > [4] > https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=status&milestone=7.2.4 > [5] https://trac.osgeo.org/grass/wiki/GitMigration#Migrationplandraft ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
Hi, po 6. 5. 2019 v 12:10 odesílatel Helmut Kudrnovsky napsal: > > In this regard I would like to ask you for ASSISTANCE. All > >tickets with milestone 7.0 [3], 7.2 [4] should be reviewed and either > >to be closed or milestone changed to 7.4 (or 7.6/7.8/8.0). > > do we have some date until when tickets should be reviewed? ASAP, we would like to finish migration in reasonable time. Ma -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] svn/trac -> git/github migration plan
hi Martin, > In this regard I would like to ask you for ASSISTANCE. All >tickets with milestone 7.0 [3], 7.2 [4] should be reviewed and either >to be closed or milestone changed to 7.4 (or 7.6/7.8/8.0). do we have some date until when tickets should be reviewed? - best regards Helmut -- Sent from: http://osgeo-org.1560.x6.nabble.com/Grass-Dev-f3991897.html ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] svn/trac -> git/github migration plan
Dear all, based on decision made by PSC [1], the GRASS GIS source code will be moved from SVN hosted by OSGeo to Git hosted by GitHub.com. More details at [2]. It's also planned to move open issues from trac to GitHub issue system. In this regard I would like to ask you for ASSISTANCE. All tickets with milestone 7.0 [3], 7.2 [4] should be reviewed and either to be closed or milestone changed to 7.4 (or 7.6/7.8/8.0). Only tickets with milestone 7.4+ will be migrated. We are assuming that 7.0 and 7.2 reached EOL. Our goal: to have open tickets only with milestone 7.4.5+. When this part will be done the migration can start, see draft [5]. Thanks for you help, feedback in advance! Ma [1] https://lists.osgeo.org/pipermail/grass-psc/2019-April/002034.html [2] https://trac.osgeo.org/grass/wiki/GitMigration#ImplementationofmigrationfromOSGeoSVNandtractoGitHub [3] https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=status&milestone=7.0.7 [4] https://trac.osgeo.org/grass/query?status=assigned&status=new&status=reopened&group=status&milestone=7.2.4 [5] https://trac.osgeo.org/grass/wiki/GitMigration#Migrationplandraft -- Martin Landa http://geo.fsv.cvut.cz/gwiki/Landa http://gismentors.cz/mentors/landa ___ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev
