Version mismatch when building trunk

Thiago Macieira thiago at kde.org
Sat Oct 17 17:23:55 BST 2009


Em Sábado 17. Outubro 2009, às 18.03.31, Kevin Krammer escreveu:
> On Saturday, 2009-10-17, Thiago Macieira wrote:
> > Em Sábado 17. Outubro 2009, às 13.44.39, Kevin Krammer escreveu:
> > > On Friday, 2009-10-16, Thiago Macieira wrote:
> > > > Em Sexta-feira 16. Outubro 2009, às 17.32.16, Kevin Krammer escreveu:
> > > > > On Friday, 2009-10-16, Thiago Macieira wrote:
> > > > > > Em Sexta-feira 16. Outubro 2009, às 08.50.19, Kevin Krammer
> 
> escreveu:
> > > > > > > On Friday, 2009-10-16, Thiago Macieira wrote:
> > > > > > > > Em Quinta-feira 15. Outubro 2009, às 23.53.18, Chani escreveu:
> > > > > > > > > so if there *is* a way for people to set up their git
> > > > > > > > > repository so that it automagically updates to the latest
> > > > > > > > > recommended qt with just a 'git pull' or whatever, can we
> > > > > > > > > have instructions for that please?
> > > > > > > > >
> > > > > > > > > :)
> > > > > > > >
> > > > > > > > There is a way, provided you never have commits of your own
> > > > > > > > on top.
> > > > > > > >
> > > > > > > > git fetch origin HEAD
> > > > > > > > git reset --hard FETCH_HEAD
> > > > > > >
> > > > > > > So if I do that now or right after a clone, do I have to repeat
> > > > > > > it before every update or does this make the KDE branch
> > > > > > > permanently work the way it is intended?
> > > > > >
> > > > > > When you clone, you get the branch that HEAD points to.
> > > > > >
> > > > > > But then you are at that branch. If HEAD points somewhere else,
> > > > > > you won't know. You need to run these commands above for every
> > > > > > update.
> > > > >
> > > > > Ok, thanks. Clone it is then.
> > > > > As a bonus it removes the need for make confclean :)
> > > >
> > > > Please don't.
> > >
> > > Relax, I won't do that every time :)
> > > Just when the requirement of KDE makes the current checkout useless due
> > > to this weird limitation.
> > >
> > > > A clone is a 170 MB transfer. A fetch is usually just a few kilobytes
> > > > -- at most 5 MB when I push a new release.
> > >
> > > Yeah, I noticed.
> > > But 170MB every several months is acceptable, even if it takes quite a
> > >  while.
> >
> > Right. You'll do a 170 MB transfer when a 0 MB transfer is enough.
> >
> > How is that acceptable?
> 
> I didn't claim that it is perfect, but it beats rebuilding Qt and
>  kdesupport twice because updating Qt did not actually update it.
> 
> As I said I do a clean build (including prior removal of build and install
> dirs) whenever updating Qt so the time needed for getting these 170MB don't
> add that much overhead.

I'm talking about the load on the server.

And why do you want to download 170 MB again when those two commands I gave 
you allow you to do with less than 1% of that?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

Qt Developer Days 2009 | Registration Now Open!
Munich, Germany: Oct 12 - 14     San Francisco, California: Nov 2 - 4
      http://qt.nokia.com/qtdevdays2009
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091017/2e1908ca/attachment.sig>


More information about the kde-core-devel mailing list