Version mismatch when building trunk

[Gary Greene]

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.
> 
> With git, we are saying "there is no default branch! you must change
> to branch XXX and keep it updated" so now I need to know what is the
> advised branch *and* have that branch updated. That makes it quite
> difficult to follow unless you keep both eyes on k-c-d, qt labs,
> planetkde and whatnot.
> 
> I think it would be easier if the master branch in git always pointed
> to the advised release. I. e. instead of cloning kde-qt.git and
> finding "master" branch is 4.5.2, therefore after cloning 4.5.2 is the
> version I have, please rename the former "master" to "4.5.2",
> "4.5.2-patched" or whatever, and rename "4.6-stable" (or
> "4.6-stable-patched", can't remember now) to "master". This way, when
> I git clone kde-qt.git, or qt.git, I am in the branch I should use to
> develop.
> 
> Now we have these branches:
>    master -> 4.5.2
>    4.6-stable-patched
>    ...
> 
> and ask people to do "git checkout -b 4.6-stable-patched
> origin/4.6-stable-patched" after cloning. Not intuitive unless you
> know git to a certain degree (more than basics). When Qt 4.7 is
> released, we'd have:
>    master -> 4.5.2
>    4.6-stable-patched
>    4.7-stable-patched
>    ...
> 
> and would ask people to checkout 4.7-stable-patched.
> 
> What we should have:
> 
> * Now:
>     master -> 4.6-stable-patched
>     4.6-rc1
>     4.5.2
>     ...
> 
> * When 4.7 is released:
>    master ->4.7-stable-patched
>    4.6-stable-patched
>    ...
> 
> etc
> 
> 
> (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)
> 
> My 2 cents.

Agreed. VCS' shouldn't be making developers jobs _harder_, but easier. 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 doesn't have the
time/inclination of wanting to learn the "dark magick" portions of a
particular version control system.

-- 
Gary L. Greene, Jr.
==========================================================================
Developer and Project Lead for the AltimatOS open source project
Volunteer Developer for the KDE open source project
See http://www.altimatos.com/ and http://www.kde.org/ for more information
==========================================================================

Please avoid sending me Word or PowerPoint attachments.