Re: [Help-glpk] Help-glpk] [Fwd: CMAKE build environment (and version control)]

[Alpar Juttner]

Hi,

> Just added a GLPK wikibook entry for LEMON:
> 
>   
> http://en.wikibooks.org/wiki/GLPK/Third-party_API_wrappers#LEMON_graph_library

Thanks for giving publicity.

> GLPK people should note the following presentation
> is well worth reading for an overview.  Knowledge
> of C++ is assumed:
> 
>   Jüttner, Alpár, Balázs Dezso, Péter Kovács.  2010.
>     LEMON : library for efficient modeling and
>     optimization in networks -- presentation.
>     Department of Operations Research, Eötvös Loránd
>     University, Budapest, Hungary.  30 April.  PDF.
> 
>   http://lemon.cs.elte.hu/pub/doc/lemon-intro-presentation.pdf

For those are in hurry, page 60-61 show an example for the usage of the
LP interface.

> I guess this is a good time to bring up the
> general question of whether GLPK should move to a
> centralized (svn) or distributed (hg, git) source
> code management system.

I think the time has already decided this. Currently, I would recommend
svn only for in some very special use-cases (e.g. when huge binary files
must be version controlled).

We used svn for quite a long time, then switched to hg. The benefit was
clear and substantial.

      * Being hg an offline tool is is much faster and seamless to work
        with.
      * It gives us more control on what gets into the repository. This
        svn if someone has a write access (s)he can do anything with any
        control, both intentionally or accidentally.
      * It "opens" the development for the non-core developers at the
        same time. Everyone can have a local copy of the repository, can
        make changes _in the same way_ as core developers do, and
        eventually may submit his changes to the official repository.

>   That said, the current
> tar-ball and occasional patch method works fine
> for me.  Linus Torvalds comments that the early
> years of Linux kernel development used tarballs
> + patches .. though I doubt they would return to
> that system now.

This is indeed the main reason for using a distributed version control
system - it is simply a tool for supporting the very same workflow.

> Fantastic to see a university project with proper
> software engineering.  Congratulations!

Thanks for the kind words!

All the best,
Alpar