Re: [Qgis-developer] Git repo available for testing
Hi On Fri, May 13, 2011 at 10:51 PM, Martin Dobias wonder...@gmail.com wrote: 8--snip-- In the official repository I have created a new branch 'browser-and-customization' that contains all the work we (Radim and me) presented on the hackfest in Lisbon. We will do some cleanups there, then merge it to master and continue polishing it there. Cool I'm going to try it out right now! Regards Tim Regards Martin -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
On Tue, May 3, 2011 at 2:23 PM, Tim Sutton li...@linfiniti.com wrote: Hi Martin (and others who need to merge changes over) On Mon, May 2, 2011 at 6:22 PM, Martin Dobias wonder...@gmail.com wrote: Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? I wrote up a guide[1] on how to migrate your changesets into git from a 'foreign' repo. The process was quite easy for me, hopefully it will be for you too. [1] http://www.qgis.org/wiki/GitMigration Your guide worked well for me, thanks. In the official repository I have created a new branch 'browser-and-customization' that contains all the work we (Radim and me) presented on the hackfest in Lisbon. We will do some cleanups there, then merge it to master and continue polishing it there. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Is this git thing on? Questions and confusion. Is there a git guide for dummies? I found http://www.qgis.org/wiki/Using_Git but it seems overly complex. I just want to do like I've done with svn - check out/update, make changes, and commit the changes. 3 steps. Git checkout itself looks complex, let alone committing a change. ...Sorry if I seem a bit resistant. Are users migrated to git? Or do I need to register with github and ask for commit access? How long until 1.7 release? I would like to do the workaround for http://trac.osgeo.org/qgis/ticket/3497 before release, and check over the Mac install/build instructions. On May 2, 2011, at 10:16 AM, Tim Sutton wrote: If you are interested in the git migration, you can test and play around with it here: http://github.com/qgis/Quantum-GIS You can go ahead and fork it and see if everything works ok for you. If we encounter any major issues, we may need to trash and repopulate it so please don't consider it production ready yet. I made detailed notes on the migration for anyone interested here: http://linfiniti.com/2011/05/some-notes-on-the-great-migration-qgis-svn-to-git/ If any git experts notice anything untoward with my procedures please feel free to suggest better working practices. I'll give it a couple of days and if nobody has any major issues, we can start to use that as our canonical repository. Next we will start to work on the trac - redmine migration (and svn commitlog - git commitlog in redmine). If anyone has particular expertise in these (especially the latter), please feel free to volunteer your services. The other directories (code examples etc under svn trunk) I will migrate after the release has gone out. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Le 07/05/2011 18:31, William Kyngesburye a écrit : Is this git thing on? Questions and confusion. Is there a git guide for dummies? I found http://www.qgis.org/wiki/Using_Git but it seems overly complex. I just want to do like I've done with svn - check out/update, make changes, and commit the changes. 3 steps. Git checkout itself looks complex, let alone committing a change. ...Sorry if I seem a bit resistant. Have a look at the help - http://help.github.com/ Here is a nice cheatsheet - http://ktown.kde.org/~zrusin/git/git-cheat-sheet-medium.png Are users migrated to git? Or do I need to register with github and ask for commit access? You need to register to github but you don't need to ask for commit access : the best way of enjoying git is to make your own fork the trunk, work on it and then push the changes back. It is still possible to have one repo with everybody writing directly to it but, Tim will correct me, that's not the choice made at the hackfest. How long until 1.7 release? I would like to do the workaround for http://trac.osgeo.org/qgis/ticket/3497 before release, and check over the Mac install/build instructions. On May 2, 2011, at 10:16 AM, Tim Sutton wrote: If you are interested in the git migration, you can test and play around with it here: http://github.com/qgis/Quantum-GIS You can go ahead and fork it and see if everything works ok for you. If we encounter any major issues, we may need to trash and repopulate it so please don't consider it production ready yet. I made detailed notes on the migration for anyone interested here: http://linfiniti.com/2011/05/some-notes-on-the-great-migration-qgis-svn-to-git/ If any git experts notice anything untoward with my procedures please feel free to suggest better working practices. I'll give it a couple of days and if nobody has any major issues, we can start to use that as our canonical repository. Next we will start to work on the trac - redmine migration (and svn commitlog - git commitlog in redmine). If anyone has particular expertise in these (especially the latter), please feel free to volunteer your services. The other directories (code examples etc under svn trunk) I will migrate after the release has gone out. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburyekyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Is ad494d4 before or after a87cb60? Is there a plan to add some sequential number to nightly builds QGIS/About? Right now the only indicator of freshness of the nightly build is suffix of the package which most of the users don't pay attention to while installig/updating. Maxim ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Hi, I like versioning systems so learning a new one is interesting. The paradoxal point with this github is as follows: (+) One of the idea is to let non-core developers contribute (make commits... in their branch only) in an easy way. I love the github tool that shows you which branch will merge easily with yours... (well, I love it when it's green). That's great. (-) Less experienced developers are not allowed to commit to the trunk because... they are less experienced; that's OK. But in the meantime, IMHO they are required to have a better understanding of git than what is required to commit directly to the main repository. Still, probably the (+) is bigger than the (-). I saw the same doubts in teams migrating from cvs to svn, and none of them wish to go back. Just my 2 cents. Mayeul Le samedi 07 mai 2011 à 11:31 -0500, William Kyngesburye a écrit : Is this git thing on? Questions and confusion. Is there a git guide for dummies? I found http://www.qgis.org/wiki/Using_Git but it seems overly complex. I just want to do like I've done with svn - check out/update, make changes, and commit the changes. 3 steps. Git checkout itself looks complex, let alone committing a change. ...Sorry if I seem a bit resistant. Are users migrated to git? Or do I need to register with github and ask for commit access? How long until 1.7 release? I would like to do the workaround for http://trac.osgeo.org/qgis/ticket/3497 before release, and check over the Mac install/build instructions. On May 2, 2011, at 10:16 AM, Tim Sutton wrote: If you are interested in the git migration, you can test and play around with it here: http://github.com/qgis/Quantum-GIS You can go ahead and fork it and see if everything works ok for you. If we encounter any major issues, we may need to trash and repopulate it so please don't consider it production ready yet. I made detailed notes on the migration for anyone interested here: http://linfiniti.com/2011/05/some-notes-on-the-great-migration-qgis-svn-to-git/ If any git experts notice anything untoward with my procedures please feel free to suggest better working practices. I'll give it a couple of days and if nobody has any major issues, we can start to use that as our canonical repository. Next we will start to work on the trac - redmine migration (and svn commitlog - git commitlog in redmine). If anyone has particular expertise in these (especially the latter), please feel free to volunteer your services. The other directories (code examples etc under svn trunk) I will migrate after the release has gone out. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ The beast is actively interested only in now, and, as it is always now and always shall be, there is an eternity of time for the accomplishment of objects. - the wisdom of Tarzan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
On Tue, May 3, 2011 at 2:23 PM, Tim Sutton li...@linfiniti.com wrote: Hi Martin (and others who need to merge changes over) On Mon, May 2, 2011 at 6:22 PM, Martin Dobias wonder...@gmail.com wrote: Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? I wrote up a guide[1] on how to migrate your changesets into git from a 'foreign' repo. The process was quite easy for me, hopefully it will be for you too. [1] http://www.qgis.org/wiki/GitMigration If you want to preserve the history of each commit just omit the squash part of the process. Thanks Tim, I will look into that soon. Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Hi Martin (and others who need to merge changes over) On Mon, May 2, 2011 at 6:22 PM, Martin Dobias wonder...@gmail.com wrote: Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? I wrote up a guide[1] on how to migrate your changesets into git from a 'foreign' repo. The process was quite easy for me, hopefully it will be for you too. [1] http://www.qgis.org/wiki/GitMigration If you want to preserve the history of each commit just omit the squash part of the process. Regards Tim -- Tim Sutton - QGIS Project Steering Committee Member (Release Manager) == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. Visit http://linfiniti.com to find out about: * QGIS programming and support services * Mapserver and PostGIS based hosting plans * FOSS Consulting Services Skype: timlinux Irc: timlinux on #qgis at freenode.net == ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Hi Tim On Mon, May 2, 2011 at 5:16 PM, Tim Sutton li...@linfiniti.com wrote: If you are interested in the git migration, you can test and play around with it here: http://github.com/qgis/Quantum-GIS You can go ahead and fork it and see if everything works ok for you. If we encounter any major issues, we may need to trash and repopulate it so please don't consider it production ready yet. I made detailed notes on the migration for anyone interested here: http://linfiniti.com/2011/05/some-notes-on-the-great-migration-qgis-svn-to-git/ great stuff :-) The repository reads 59 branches and 82 tags. In my opinion we should: - remove all ancient tags not related to releases - like root-before-SDTS-branch - change all release branches to tags - remove all branches that have been merged or not touched for more than 1-2 years - for releases adopt a strategy e.g.: create release branch from master, do release-related commits there, when finished create a release tag and remove the release branch ... we would end up with just few active branches and tags marking releases or other important milestones. Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? Finally I have one major concern I have forgotten to discuss during the hackfest. There will be no commit revision numbers anymore, so developers will barely stay motivated to develop QGIS knowing that we will never reach (and celebrate) revision 16000 or 2 (btw. now we are at r15861). Do you have any solution for that? Git's sha1 hashes for the commits may bring in some fun too, though they seem quite random :-) Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Git repo available for testing
Hi On Mon, May 2, 2011 at 6:22 PM, Martin Dobias wonder...@gmail.com wrote: Hi Tim On Mon, May 2, 2011 at 5:16 PM, Tim Sutton li...@linfiniti.com wrote: If you are interested in the git migration, you can test and play around with it here: http://github.com/qgis/Quantum-GIS You can go ahead and fork it and see if everything works ok for you. If we encounter any major issues, we may need to trash and repopulate it so please don't consider it production ready yet. I made detailed notes on the migration for anyone interested here: http://linfiniti.com/2011/05/some-notes-on-the-great-migration-qgis-svn-to-git/ great stuff :-) The repository reads 59 branches and 82 tags. In my opinion we should: - remove all ancient tags not related to releases - like root-before-SDTS-branch Agreed - we discussed this a bit on IRC but I wasnt sure if people were in a 'keep every bit' mindset or a 'don't let the world know how cluttered our minds are' mindset. Unless there are objections, I will clean away some of the obviously crufty bits. - change all release branches to tags Ok I can do that easily enough. - remove all branches that have been merged or not touched for more than 1-2 years Yup agreed - for releases adopt a strategy e.g.: create release branch from master, do release-related commits there, when finished create a release tag and remove the release branch Yup also good. ... we would end up with just few active branches and tags marking releases or other important milestones. I would probably keep the last release running as a branch until the next release comes out and then last gets tagged, new gets branched. Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? Ok thats one of the sucky things about using git svn approach and one of the main reasons I wanted to get away from git svn to pure git. With git svn each clone gets distinct git hashes for each commit so two separately cloned repos can never marry up again. In your case I think sourcepole clone was created independently of qgis community clone so the only way to get your changes into qgis community was to : commit to sourcepole repo git svn dcommit to push changes into svn git svn rebase on a clone of qgis community repo git push the changes up to the community repo For now if you are working on one of the old svn originated repos you probably still need to deal with that - except now svn dcommit rebase arent there so you will need to create a patch or manually overwrite files in a git community clone from your sourcepole clone. Feel free to correct me if I got any of that wrong git experts Finally I have one major concern I have forgotten to discuss during the hackfest. There will be no commit revision numbers anymore, so developers will barely stay motivated to develop QGIS knowing that we will never reach (and celebrate) revision 16000 or 2 (btw. now we are at r15861). Do you have any solution for that? Git's sha1 hashes for the commits may bring in some fun too, though they seem quite random :-) Actually, this is a large benefit of moving to git for me. I can't think how many times I have been about to commit when someone else pipped me at the post: http://trac.osgeo.org/qgis/browser?rev=1000 Gary http://trac.osgeo.org/qgis/browser?rev=2000 anonymous (cvs2svn) http://trac.osgeo.org/qgis/browser?rev=3000 Gavin http://trac.osgeo.org/qgis/browser?rev=4000 Mark http://trac.osgeo.org/qgis/browser?rev=5000 Martin http://trac.osgeo.org/qgis/browser?rev=6000 Gavin http://trac.osgeo.org/qgis/browser?rev=7000 Tim http://trac.osgeo.org/qgis/browser?rev=8000 Marco http://trac.osgeo.org/qgis/browser?rev=9000 Tim http://trac.osgeo.org/qgis/browser?rev=1 Otto http://trac.osgeo.org/qgis/browser?rev=11000 Juergen http://trac.osgeo.org/qgis/browser?rev=12000 Werner http://trac.osgeo.org/qgis/browser?rev=13000 Radim http://trac.osgeo.org/qgis/browser?rev=14000 William http://trac.osgeo.org/qgis/browser?rev=15000 William Now I no longer need to feel bent and frustrated about not hitting those 1000 based revisions. Anyway, generating sequential commit numbers in git should be trivial to do following this recipe: - write to Linus Torvalds and ask him to change git so that it uses sequential numbers (and update the entire kernel source so that it uses the new numbering) - write to every person who has a git repository and ask them to update to Linus's new version of GIT and rehash their version numbers - delete any revision if there is another revision in a competing tree with the same number I could continue with more detail, but I'm sure you get the picture :-) Regards Tim Cheers Martin
Re: [Qgis-developer] Git repo available for testing
On Mon, May 2, 2011 at 9:22 AM, Martin Dobias wonder...@gmail.com wrote: great stuff :-) The repository reads 59 branches and 82 tags. In my opinion we should: - remove all ancient tags not related to releases - like root-before-SDTS-branch - change all release branches to tags - remove all branches that have been merged or not touched for more than 1-2 years - for releases adopt a strategy e.g.: create release branch from master, do release-related commits there, when finished create a release tag and remove the release branch ... we would end up with just few active branches and tags marking releases or other important milestones. Then I have a question regarding merging stuff from other repositories. For example customization we have done with Radim is based on Sourcepole clone, Pirmin's globe work is also based on that clone. Those are repositories with a different base, so I would expect that merging will not work automatically. Anyone has some experience with such use case? Finally I have one major concern I have forgotten to discuss during the hackfest. There will be no commit revision numbers anymore, so developers will barely stay motivated to develop QGIS knowing that we will never reach (and celebrate) revision 16000 or 2 (btw. now we are at r15861). Do you have any solution for that? Git's sha1 hashes for the commits may bring in some fun too, though they seem quite random :-) `git describe` will return the number of commits since the last tag or some other reference point of your choosing if you need a linear commit number to track. Another thing that can help developer motivation is `git shortlog -s -n` which computes the number of commits per author and displays a sorted list. -Charlie Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
