[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alpar Juttner
Subject: Re: [Help-glpk] Help-glpk] [Fwd: CMAKE build environment (and version control)]
Date: Mon, 13 Dec 2010 07:36:32 +0100


> Just added a GLPK wikibook entry for LEMON:

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.

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
      * 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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]