Hi On Mon, May 2, 2011 at 6:22 PM, Martin Dobias <[email protected]> wrote: > Hi Tim > > On Mon, May 2, 2011 at 5:16 PM, Tim Sutton <[email protected]> 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 20000 (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=10000 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 > -- 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 [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
