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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest