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
