Version mismatch when building trunk

[Kevin Krammer]

On Saturday, 2009-10-17, Thiago Macieira wrote:
> 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.

Good point

> 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?

Alright, I'll try to remember the mail with that workaround next time updating 
fails.

Who knows, maybe somebody will create a subversion repository with KDE build 
dependencies before that happens again.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- 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/3a11e4cc/attachment.sig>