Version mismatch when building trunk

[Andreas Pakulat]

On 16.10.09 11:41:50, Gary Greene wrote:
> On 10/16/09 11:14 AM, "Pau Garcia i Quiles" <pgquiles at elpauer.org> wrote:
> >> So we really want to switch to git at some point in the future ?
> >> I've seen several times now in the last weeks to some git-related question an
> >> answer like "you just need to do "$ git magic spell of the day" and it will
> >> work" that I have slight doubts that it might be just too complicated.
> >> With svn/cvs I just needed co/update/commit/diff, sometimes status/log, very
> >> rarely blame/copy/move. What I have seen here for git looked so much more
> >> complicated, and additionally it seems I still have to actually _learn_ how
> >> to deal with all the branches, trees, roots, etc, while I basically just want
> >> HEAD and the current release branch.
> > 
> > IMO problem is we are not only changing VCSs but also changing paradigms.
> > 
> > In Subversion, the default branch always had the advised stuff. The
> > only thing I had to take care of is "svn up" to update sources.
> > 
> > (I've used 4.7 instead of 4.6 RC1, 4.6 beta 1, etc so that it's easier
> > to understand what I mean: "master" should always be the latest Qt
> > used to develop KDE, at least in kde-qt.git)
> 
> Agreed. VCS' shouldn't be making developers jobs _harder_, but easier.

If I have to pay the price of a bit more explicitly with my VCS commands
to get the result that gitk --all shows me on the kde-qt clone then so
be it. You'll never get that kind of history tree managed with svn.

> This means that while this is a little extra work for the merge dude,
> it's far easier on the Git challenged/novice KDE programmer that

Well, git-challenged can be easily cured. In fact for keeping track of
kde-qt you need exactly two very easy to learn commands: git branch and
git pull. The first one to select the right branch and the latter to
keep that branch up-to-date.

I'm currently undecided wether deviating kde-qt's master branch from
that of the qt repository, to have it always point to the "advised" Qt
version, is good or bad. But it definetly creates a major difference in
a repo thats "just" a clone of the original + a couple of patches.

And novice-kde programmers should not really have the need to fetch Qt
from the repository, for those a stable Qt+KDE (libs) release should be
far better.

> doesn't have the time/inclination of wanting to learn the "dark
> magick" portions of a particular version control system.

git branch and git pull are not even coming close to the "dark magick
portions" of git. In fact you're not even hitting those portions when
doing everyday work with git - at least by my experience in the last 3
weeks working fulltime with a git repo.

Andreas

-- 
Your motives for doing whatever good deed you may have in mind will be
misinterpreted by somebody.