[Qgis-developer] Git repo available for testing

[Tim Sutton]

Hi

On Mon, May 2, 2011 at 6:22 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
> Hi Tim
>
> On Mon, May 2, 2011 at 5:16 PM, Tim Sutton <lists at 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 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
==============================================