Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Guide for building C::B on Linux request due to wiki 502 error

<< < (5/5)

cacb:

--- Quote from: AndrewCot on November 21, 2021, 10:58:02 am ---Sorry, but I am not a SVN user, apart from fetching C::B from SF. As such some of the SVN info below I only just looked up.

--- End quote ---

Thank you for a lot of info, I am also not an SVN user  8) . Let me clear up some points, though. Note that my ambition is not to reform the Code::Blocks main repository, I just want a convenient mirror on Github. 

Ideally, if you 'git clone' from that mirror, the result should be the same as for 'svn checkout' from the original SVN repo. It turns out that this is not 100% the case now because the contrib plugins FortranProject and PythonPlugins are missing. So why are they missing?

It turns out that in SVN you have something called svn externals which is kind of similar to git submodules, but not quite. SVN Externals are references to separate SNV repos, but svn externals and git submodules are sufficiently different that git-svn doesn't support externals. There are many discussions like this on the net, but no really obvious solutions for a case like this, or at least I haven't found one.

For now, developers who want to build C::B with plugins FortranProject and/or PythonPlugins should use the svn repo directly. I can't really see how a github mirror can accomodate such externals without messing with the commit history. At least it would require some research to come up with a solution, and personally I don't use those plugins.

If the repositories all migrated permanently to git, then FortranProject and PythonPlugins could become git submodules.

Your points:

1. See above
2. See above
3. Yes you can build a Fortran project without the FortranProject plugin, but maybe miss some features like debugging.
4. Those arrows indicate svn externals

To obtain a git mirror with all external plugins require solving the svn externals => git incompatibility issue.

AndrewCot:
In total agreement.

gd_on:
May be a simple solution is that Darmar (the FortranProject plugin author) creates a git copy synchronized of his svn repository. Then adding a git submodule is easier.
The same for other plugins as python probably.

cacb:

--- Quote from: gd_on on November 22, 2021, 09:43:42 am ---May be a simple solution is that Darmar (the FortranProject plugin author) creates a git copy synchronized of his svn repository. Then adding a git submodule is easier.
The same for other plugins as python probably.

--- End quote ---
I think the following is true:

If the original C::B repo is in svn, then the contrib repos must be svn also (referenced as svn externals). If the original C::B repo is in git, then then the contrib repos must be git also (referenced as git submodules or git subtrees). I do not believe it is possible to mix.

If all repos were mirrored to git, you would still have to manually modify the C::B mirror to reference the git mirrors instead of the original svn externals. But maintaining this would require additional commits so it can't be done in the master branch and would as a minimum require a separate git branch just to handle this I think (I could be wrong as there are many things in git I don't know that well). Maybe this is workable, not sure.

So it isn't really straightforward to support the svn externals unless all move permanently to git.

--- thinking loud:

Another elaborate scheme I thought about was using the git-svn-clone-externals scripts which creates symlinked local git-svn clones of svn externals to create an effect in git that resembles the original svn external. But it only works locally on linux with symlinks, and you can't push it to github in any meaningful way.

Even more elaborate would be to modify the git-svn-clone-externals script to create a git subtree instead of a linux symlink. This would also have to happen in a separate branch. In this case it would be possible to push the result to github and everyone would get a complete copy similar to svn. But I have not researched if this can be maintained easily. Again a separate branch would be needed I think. And yes, it sounds like a lot of work.

Navigation

[0] Message Index

[*] Previous page