[Kde-graphics-devel] Re: kdegraphics git: Repositories, conversion date

Marcel Wiesweg marcel.wiesweg at gmx.de
Fri Feb 11 21:18:04 CET 2011

> - looks like all the tags are in a "detached" empty commit and not
> directly on the branch they belong to; is it possible to fix that?

I would assume the fact that the SVN commit message of the SVN tagging commit 
is linked with the tag plays a role, but really I dont know. You could ask 
kde-scm-interest for clarification.

> - kdvi code imported in 3812c43da5: wouldn't it be possible to have the
> kdvi/kviewshell trunk only code in a separate branch, and do the file
> moves as branch merge?

Sure, that should be possible

> - 8979884f8d adds the epub plugin, but in the /epub directory instead of
> /generators/epub; this cases the duplication of the epub code, when the
> plugin is moved from kdereview to kdegraphics (9dcb4b614e); ideally,
> cold the plugin development be done in a separate branch (called eg
> "epub"), merged to master when doing the kdereview->kdegraphics move?

I can try this, let's see if it works. I hope then that svn2git will 
automagically see the merge. It should.

> - there are ome files in cmake/ that should be considered as they were
> in okular/cmake:
>   cmake/CMakeLists.txt
>   cmake/modules/CMakeLists.txt
>   cmake/modules/COPYING-CMAKE-SCRIPTS
>   cmake/modules/FindCHM.cmake
>   cmake/modules/FindDjVuLibre.cmake
>   cmake/modules/FindEPub.cmake
>   cmake/modules/FindLIBGS.cmake
>   cmake/modules/FindLibSpectre.cmake
>   cmake/modules/FindPoppler.cmake
>   cmake/modules/FindOkular.cmake [deleted few months ago]
> would be possible to do that?

Yes, this should be possible. At least, I can take the mentioned *.cmake files 
out, you may need to manually add the CMakeLists.txt

> - mobipocket plugin:
>   - c31d19656a imports the mobipocket plugin from kdereview, without
>     any previous history?
>   - ae4af6bbc2 deletes it all, and its files are added when committed
>     later
>   - as before, would it be possible to have it as separate branch?

same as above

> > - all orphaned KDE/x branches fixed that I found (usually due to
> > cvs2svn weirdness)
> Shouldn't they be called simply X (instead of KDE/X)?

The discussion on kde-scm-interest did not lead to a clear result for me. How 
do the other KDE SC modules call it?

I will try to fix the rules tomorrow, takes some hours then to run.


More information about the Kde-graphics-devel mailing list