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

[Michael Leupold]

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 :-)

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?


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.


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.


Thanks and regards,
Michael