[kde-doc-english] Frozen kdelibs, new entities and other Kate/KWrite troubles

[Albert Astals Cid]

El Dimarts, 22 de novembre de 2011, a les 11:11:30, Freek de Kruijf va 
escriure:
> On dinsdag 22 november 2011 00:34:43 Albert Astals Cid wrote:
> > There is no kdelibs 4.8 (it does not exist), also it does not make sense
> > for you to push to 4.6 as there are no more releases of it anymore.
> 
> I still did push the new version of .../customization/nl/user.entities to
> KDE/4.6 in the hope there is a parallel path by a distributor to take that
> file and put it in the distribution still using 4.6 like earlier versions of
> openSUSE. I do see new versions of localization files of KDE coming into my
> system, while I still use KDE 4.6.
> The file .../customization/nl/user.entities is the only file in kdelibs, in
> the few years I coordinate the Dutch translations, that I needed to change.
> 
> > Let me try to explain the main difference between svn and git regarding
> > branches
> > 
> > in svn each branch had a different url, e.g.
> > /trunk/KDE/kdelibs
> > /branches/KDE/4.7/kdelibs
> > etc
> > 
> > in git everything has the same url, e.g.
> > git://anongit.kde.org/kdelibs
> > contains ALL the kdelibs branches
> > 
> > So when you do
> > git clone git://anongit.kde.org/kdelibs
> > you end up with master (what was called trunk before) in a folder named
> > kdelibs
> > 
> > If you want to switch to a different branch, you just switch to it from
> > within the same repository (folder), doing
> > git checkout master
> > git checkout KDE/4.7
> > git checkout KDE/4.6
> > etc
> 
> So it really is a turning stage and you have to give the above command to
> see the files in that version.
> 
> > You can view all the existing branches with git branch -a
> > 
> > Then depending which branch you have checked out
> 
> Having this branch checked out and left it alone for some time, I use(d)
> git pull --rebase
> to make it current or should I use the checkout command again?

You need to pull + rebase after each checkout to make sure you have all the 
new stuff of the branch you just switched to.

> 
> When I need to change something first I do the above to make it current and
> after that put my changes in and give the command
> 
> git commit -a -m 'some text about the type of change'
> 
> then I continue like below.
> 
> > you need to push to the
> > same branch (otherwise very bad things can happen), that is
> > git push origin master
> > git push origin KDE/4.7
> > git push origin KDE/4.6
> > 
> > This should give you a quick overview of how git works, but i recommend
> > that you read some of the tutorials out there. If you do not have time
> > for that, just send me the patches you need to commit to kdelibs.
> > 
> > > How do these changes in kdelibs boil down to a distribution? Are
> > > they
> > > only part of a minor release of KDE or is there a separate work flow
> > > for changes that are made in the area where localized information
> > > is produced, like kdelibs, but also in the i18n svn repository. So
> > > a distribution can regularly pick up these packages, apart from the
> > > minor releases of KDE.
> > 
> > Distributions use tarballs that we release with every minor release like
> > they always have done.
> 
> Like I wrote above, I do see new versions of packages coming in recently in
> KDE 4.6 with localized data, like kde4-i18n-nl.
> Thinking about this, it may be new localized data from KDE packages that
> have their own version scheme. So can you enlighten us on this? I will ask
> openSUSE as well.

openSUSE might be updating from SVN, that is non standard and regular distros 
update from packages, that's why we make them.

Albert