converting QMake plugin

Milian Wolff mail at milianw.de
Fri Dec 3 10:55:47 UTC 2010


On Friday 03 December 2010 05:40:28 Nicolás Alvarez wrote:
> 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.

Awesome! Thanks a million Nicolas, I'll push it to the final location now.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20101203/a1de241d/attachment.sig>


More information about the KDevelop-devel mailing list