trunk/kdeedu/klettres

[Thiago Macieira]

Andras Mantia wrote:
>and in KDE you have:
>/
>trunk
>  project1
>     my_branch
>  project2
>     my_branch2

That's not the layout I proposed.

The layout I proposed is:
/
trunk
  project1
  project2
branches
  KDE
    4.0
      kde-common
      kdelibs
      kdebase
      [...]
  project1
    4.0
    4.1
  project2
    0.2
    0.3
tags
  project1
    4.0.0
    4.0.1
    4.1.0
work
    project2-kpart
    project2-qt4

So, explaining better:

trunk: where normal development occurs. This is the next release of the 
application/project. Like HEAD in CVS.

branches: when a release occurs, like KDE_3_3_BRANCH. Note I am also 
proposing a project called "KDE" which would have the main projects 
(kdelibs, kdebase, kdepim, kdenetwork, etc.)

tags: just that: tags. Official releases. Exactly like branches in layout.

work: work branches. Now this is an idea of mine. Why did I separate work 
branches from release branches? Because we have too many branches 
already, which makes /branches/ really crowded. The idea here is that you 
create a branch to do some special work and then merge back into the 
official one in /trunk (like, experimental porting to Qt4, redesigning 
the app around a KPart, etc.)

The important thing about work is that you *erase* the branch once you're 
done! This is not CVS! Branches don't have to live forever!

>I'm not sure which is better. In case of simply doing some
>"make_it_cool" thing, the second might be OK, but when a new release is
>made and the repository is branched, I'm not sure that either of the
>above would be good. In that case maybe a

Please don't name branches "make_it_cool".

So, the Release Dude would do this to create the KDE 4.0 release:
svn mkdir branches/KDE/4.0
for module in kde-common kdelibs kdebase kdepim kdenetwork kdemultimedia 
kdeadmin kdeartwork [...]; do
  svn cp trunk/$module branches/KDE/4.0
done
svn commit

Or, if we don't care about marking the extragears, www, etc. as "KDE 4.0 
branch", one could do the following (no mkdir):
svn cp trunk branches/KDE/4.0
svn commit

The amarok developer releasing version 1.3:
svn cp trunk/kdeextragear-1/amarok branches/amarok/1.3
svn cp trunk/kdeextragear-1/amarok tags/amarok/1.3.0
ln -sf ../../KDE/3.4/kde-common/admin branches/amarok/1.3/admin
ln -sf ../../KDE/3.4/kde-common/admin tags/amarok/1.3.0/admin
svn commit

The Quanta developer creating a branch to work on supporting XHTML 2.0:
svn cp trunk/kdewebdev/quanta work/quanta-xhtml2
svn commit

Switching to the XHTML 2.0 support branch:
cd trunk/kdewebdev/quanta
svn switch https://svn.kde.org/home/kde/work/quanta-xhtml2

When you're done, merge the changes (still switched):
cd trunk/kdewebdev/quanta
svn switch https://svn.kde.org/home/kde/trunk/kdewebdev/quanta
svn merge https://svn.kde.org/home/kde/work/quanta-xhtml2
svn commit

And erase the stale branch:
svn rm https://svn.kde.org/home/kde/work/quanta-xhtml2

The current layout of the KDE CVS isn't very "Subversion-friendly". We 
have our modules which are released in conjunction (kdelibs, kdebase, 
etc.), but we have modules that aren't released at all (extragears, www). 
If we wanted to make it friendlier, we would have to reorganise 
everything. I am not sure people would welcome such a drastic change.

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

4. And æfter se scieppend ingelogode, he wrát "cenn", ac eala! se 
rihtendgesamnung andswarode "cenn: ne wát hú cennan 'eall'. Ástynt."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050219/d349c625/attachment.sig>