converting QMake plugin

Nicolás Alvarez nicolas.alvarez at gmail.com
Fri Dec 3 04:40:28 UTC 2010


On 01/12/2010, Milian Wolff <mail at milianw.de> wrote:
> Nicolás Alvarez, 30.11.2010:
>> I was going to list the potential disadvantages to "unmerging", and
>> while writing them I noticed they are all quite irrelevant: past
>> revisions may become unbuildable because CMakeLists.txt expects the
>> builder in a subdir, and SVN commits that modify both plugins wouldn't
>> appear in the same git commit.
>>
>> It will be definitely easier to write the rules keeping both plugins
>> in separate repos, so I'll start with that right now.
>>
>> Milian: what do you think? Split qmake and qmakebuilder into separate
>> repos or not?
>
> If it makes it easier for you, why not. If it would be possible though, I'd
> personally prefer to have it in one dir as the plugins depend on each other,
> the builder has no value without the manager and vice versa.

OK, I managed to write quite perfect rules for converting qmake and
the builder into a *single* git repository.

Features of the converted repo:

1. The repository starts by adding stuff to a 'qmake' directory.
Changes are done there. Later, a 'qmakebuilder' directory is added.
The root only has 'qmake' and 'qmakebuilder' directories, no other
files.

Later, when the plugins were merged, everything in "qmake" is moved
into the root, and the repo root now contains eg. qmakemanager.cpp
next to the "qmakebuilder" directory. This way, the repo doesn't stay
with a single "qmake" directory in the root.

2. History goes all the way back to August 2005. That was in *very*
early days of KDevelop4.

3. SVN commits affecting both plugins also appear as single git
commits modifying both plugin directories (unlike my initial attempt
that would have had the two plugins as independent branches that then
merged).

4. The three qmake branches have their history perfectly converted,
including merges in both directions (branch→trunk and trunk→branch).
Some merges were converted automatically by svn2git, others manually
crafted with filter-branch.

Only problem with branches is that eg. when "qmake/parser" was
branched, the initial commit to the branch deletes everything else in
the tree other than the parser. This would be a PITA to fix, but it's
not too important anyway; history in the trunk isn't affected.

5. The entire repository history passes all git.kde.org audits; so it
can be pushed without asking sysadmins to disable hooks.


I pushed it to a scratch repo if you want to check it:
http://gitweb.kde.org/scratch/nalvarez/kdev-qmake.git

This can be the final repo (just re-push to final location), unless
someone has an objection, or scripty commits again and I have to rerun
the conversion.

-- 
Nicolas




More information about the KDevelop-devel mailing list