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

[Andreas Pakulat]

On 27.02.10 19:46:16, Thiago Macieira wrote:
> Em Sábado 27. Fevereiro 2010, às 19.37.02, Andreas Pakulat escreveu:
> > - 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.

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.


 
> > - 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?

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).
 
> > - 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.

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?

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).

> And add the rules to match the branch that was there in branches/KDE/3.5.

Yeah I think with a bit of work and looking at the svn log I should be
able to re-construct the branches in git.

Btw, does anybody know of a tool that visualizes svn history similar to
gitk? That would (hopefully) make following this stuff a bit easier.

> > 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.

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.

Andreas

-- 
Today is the first day of the rest of your life.