[Kde-scm-interest] How to handle conversion errors

[Thiago Macieira]

Em Sábado 27. Fevereiro 2010, às 19.37.02, Andreas Pakulat escreveu:
> Hi,
> 
> feel free to just send me off to some website/doc-file that tells me how
> to do this.
> 
> So I've tried to convert kdevelop from svn to git with svn2git.
> Unfortunately the result shows a couple of problems:
> 
> - some tags and branches exist multiply, i.e. I have 3.9.93 and
>   3.9.93_973742, I guess this is because of full re-tagging, do I just
>   add rules that ignore the the revisions that are listed in xxx_<rev>?

Yes. You don't need to change the rules file. Simply delete the branches and 
tags that don't interest you once the conversion is done.

> - tags that have changed as a revision from trunk has been merged in
>   look slightly off in gitk:
>   *
> 
>   |  *
>   | 
>   | /
> 
>   *

Do you mean the commit is outside the main commit history? Yes, that's 
expected. It's normal behaviour.

> - Some kdevelop releases where done as part of KDE 3.5.x but they don't
>   have the same patch-level version, I guess I need to handle these tags
>   manually?

Not following. Can you clarify?

> - moving around for KDevelop 3.x. Initially KDevelop 3.3 was part of KDE
>   3.5, 3.4 was developed separately in branches/kdevelop/3.4. Then at
>   some point branches/KDE/3.5/kdevelop was moved to
>   branches/kdevelop/3.3 and 3.4 was moved to branches/KDE/3.5/kdevelop.
>   Then we copied KDE/3.5/kdevelop to branches/kdevelop/3.5 to work on
>   3.5 release there. For KDE 3.5.8 we merged various changes to
>   branches/KDE/3.5/kdevelop and tried to keep both in sync until we
>   dropped branches/kdevelop/3.5 completely
> 
> Any suggestions how to handle these cases to get a proper history would
> be appreciated. Especially the latter seems to be kinda complicated.

Following the trunk is easy. Just add more rules with a master output branch. 
And add the rules to match the branch that was there in branches/KDE/3.5.

This only works for full branching. It doesn't work for partial checkouts.

> Last but not least it seems there are some tags that don't relate to any
> history at all. I'm guessing they've been created from branches that
> don't exist anymore right now. Am I right that adding a rule for the
> path with a specific min/max revision would help with that?

Without an example, we can't tell. And you can simply delete useless things at 
the end of the import.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20100227/240e0477/attachment.sig