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 _______________________________________________ Kde-scm-interest mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-scm-interest
