[Kde-pim] Git migration status

[Thomas McGuire]

Hi,

On Friday 16 April 2010 21:30:26 Torgny Nyblom wrote:
> an update on how the rules for the git migration are doing.
> 
> KDEPIM:
> * 1.13 GiB transfer
> * 1.3 GiB on disk
> * No diff (against the trunk of my cloned svn repo)
> * No extra files/dirs
> * No missing files/dirs (except empty dirs as git cannot handle that)
> * Number of WARNINGS: 1422 (according to Thomas script)
> * Number unique WARNINGS: 190 (according to Thomas script)

1.13 GiB is big, it means I nearly need 100 minutes to clone that. For me 
personally, that would be borderline ok, but this might not be very newbie 
friendly. What do other developers think about this size?

If it turns out the repo is considered too big, we should reduce it. The 
following comes to my mind, and it should then be measured how much size these 
methods save.
- Splitting off the e35 and e4 branches into their own repo
- Looking if there are/were single big files that cause a big increase in size
- Cutting off the history at some defined date
 
> KDEPIMLIBS:
> * 16 MiB transfer
> * 41 MiB on disk
> * No diff (against the trunk of my cloned svn repo)
> * No extra files/dirs
> * No missing files/dirs (except empty dirs as git cannot handle that)
> * Number of WARNINGS: 884 (according to Thomas script)
> * Number unique WARNINGS: 88 (according to Thomas script)
> 
> KDEPIM-RUNTIME:
> * 17 MiB transfer
> * 19 MiB on disk
> * No diff (against the trunk of my cloned svn repo)
> * No extra files/dirs
> * No missing files/dirs (except empty dirs as git cannot handle that)
> * Number of WARNINGS: 415 (according to Thomas script)
> * Number unique WARNINGS: 47 (according to Thomas script)
> 
> All warnings seem to come from copy/merge/move in svn.
> Most[1] revisions I've checked are "fake" loss of history. Meaning that
> "git gui blame" will follow fine but git log will not.
> 
> History is currently broken when subdirs/files are moved/copied/merged from
> playground/kdereview, should rules be added for this too? If so any
> volunteers to help track down what dirs and when?

I personally think it would be nice to have the history, but not as important 
as other parts of the history.
As for tracking down the directories and revisions: Does looking at the 
revisions that the script produces as warnings not work? I thought those would 
be the revisions were the history was cut off, and therefore punching in those 
revisions to WebSVN should give you the diff that includes from which 
directory the stuff was moved/copied.

> Help needed to check what branches are not in the rulefiles since it's here
> history is lost.

What do you mean, are you talking about former SVN branches now being Git 
branches, or about the need to write more rules for moves between branches?
For the former, I would need to check that by cloning the repo, have you 
uploaded a new copy already? For the later, isn't that again about writing 
more rules for copies and moves and identifying the branches and revision 
where history got lost?

> Since my server is getting tired after running conversions the last XX days
> in a row I will take a break for a day or three to let it cool down :)
> (it's in a not so ventilated closet and conversion runs seem to take
> longer and longer for each run...)

Thanks again for all your invaluable effort, without you we would be nowhere 
in the Git migration process. Do let your server cool down a bit :)

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100418/70933cd4/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/