converting QMake plugin

[Andreas Pakulat]

On 03.12.10 01: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.

Great work, just to make sure: Did you put the svn2git rules and the
instructions for git-filter-branch into the apropriate file in kde's
svn-rules git repo already?

Andreas

-- 
Stay away from hurricanes for a while.