[Kde-scm-interest] Re: Handling working branches and copies

[Torgny Nyblom]

On Sat, 02 Oct 2010 19:32:13 +0200
Michael Leupold <lemma at confuego.org> wrote:

> Hi there,
> 
> I just started playing around with svn2git. After successfully
> managing getting some of my playground stuff to work, I decided to
> give kwalletd a try. Maybe not the best choice, given it lives in
> kdebase and is pieced together from various parts of kdelibs :-)

A good way of learning :)

> One problem I stumbled upon is that I'm not quite sure about how to
> handle working branches and copies. Examples:
> 
> 
> 1. During kde4 porting there were 2 branches, namely 
> /branches/work/kdelibs4-dbus (branched from 
> /branches/work/kdelibs4_snapshot, branched from /trunk/KDE/kdelibs)
> and /branches/work/kde4/kdelibs. Questions coming to my mind:
> 
> - Should I always keep those as separate branches?
> - If so, are there already default branch names for those types of
> branches? I think naming /branches/work/kde4/* branches the same
> would be good for consistency.
> - Should I try put a branch's commits into master if there are no
> commits on trunk in between creating and merging the branch?

As far as I know there are not official guidelines on this.
What I've done (am doing) with kdepim* is to try and keep branch names
close to the SVN branch names and keep the history (branching an
merging) as it was in SVN.

The only exception is kdereview and playground, those I'm treating as
branches at the moment. 

> 2. In my early days of working on KDE, I created a branch called 
> /branches/work/kdelibs-kwallet for working on some kwallet features.
> I made some commits on it but abandoned most of what I had planned
> for in favour of working on ksecretservice. In the end, only 1 commit
> was merged with trunk (remainder abandoned). The merge commit even
> kept the original commit message. Question:
> 
> - Is there a threshold regarding number/importance of commits as to
> when I should make a branch in svn a branch in git? Eg. for this
> single commit it doesn't seem worth it.

Yours/maintainers/module maintainers call.
 
> 3. I have some commits where KWallet-related files inside kdelibs are 
> copied, eg.
> 
> (1) /trunk/KDE/kdelibs/kwallet/client/kwallet_export.h
> => (2) /trunk/KDE/kdelibs/kwallet/backend/kwallet_export.h
> 
> Generally not a problem, however in this particular case (1) will end
> up in the kdelibs git repository, (2) will end up in the kdebase git
> repository. Question:
> 
> - Should I always keep a copied file's history in such cases? Ie. it
> doesn't seem to be worth the trouble in this case.

Yours/maintainers/module maintainers call.


/Regards
Torgny