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

[Thiago Macieira]

Em Domingo 28. Fevereiro 2010, às 00.08.15, Andreas Pakulat escreveu:
> Well, its ugly compared to those tags that don't have additional changes
> merged in. That is I have this:
> 
> master
> *    --warnings
> |  * <v3.9.95> merge r1014461
> | /
> *   increase Qt requirement
> 
> But I'd rather like to have:
> 
> master
> *
> |
> * <v3.9.95> r1014461
> |
> * increase Qt requirement.

You should have thought of that before moving the tag in Subversion.

You can't have that in Git because that's not what happened.

> Well, this is mostly because my tags-rule looks like this:
> match /tags/KDE/([^/]+)/kdevelop/
>   repository kdevelop
>   branch refs/tags/v\1
>   annotated true
> end match
> 
> And hence I get a tag v3.5.10 even though there was never such a release
> (its 3.5.4, released together with KDE 3.5.10).

Yeah, you have to manually select what the numbers translate to, if you're not 
using the KDE path components.

> > Following the trunk is easy. Just add more rules with a master output
> > branch.
> 
> Hmm, so lets say I have trunk, it was copied to qt4-convert-branch,
> which was later merged back to trunk (and replaces almost all the code
> in trunk). Right now I only see the merge-commit in the history, to get
> the individual commits from the qt4-convert-branch I'd just have to list
> that for master output branch?

Yes. And clearly you'd not list trunk as the source of master. You have to 
either save that in a separate branch, or you have to ignore those commits.

> Whats the easiest way to find such moves in the svn history (as most of
> the branches have been deleted after the move back to trunk).

svn log -v --stop-on-copy $URL
then follow the URL it was copied from

> > Without an example, we can't tell. And you can simply delete useless
> > things at the end of the import.
> 
> I get this:
> 
> master
>  * fix compile with current gcc
>  |
>  | * <v2.1.1> kdevelop 2.1.1
>  | * <v2.1> kdevelop 2.1
>  |
>  * made messages
> 
> i.e. tags and related commits that don't have any parent commit. Yes I
> can remove them, but I'm wondering wether this may point to some commits
> being missed out.

That shouldn't happen. It means the tool could not figure out where the tag 
and/or branch was copied from, so it couldn't generate the proper Git history. 
I can think of three possibilities:

1) bug in the tool
2) the SVN commits were not copy-with-history
3) the SVN paths they were copied from did not match any rules

Note that "match any rules" here has a problem with the ending slash. I'm not 
sure if this is dealt with, but if you copy a directory, the directory has no 
ending slash. So the rule may not match.

-- 
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/20100228/f5f9aa7a/attachment.sig