[Kde-scm-interest] How to handle conversion errors
thiago at kde.org
Sat Feb 27 19:46:16 CET 2010
Em Sábado 27. Fevereiro 2010, às 19.37.02, Andreas Pakulat escreveu:
> 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
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
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
More information about the Kde-scm-interest