|branches||2016-12-29||sf-mensch||[r293] created branch for bugfixing of the "simple" BP...|
|tags||2012-06-14||sf-mensch||[r1] Changed svn structure for new area contributions|
|trunk||2018-04-16||cobcoder||[r625] HOME and END keys toggle on current position. [...|
|README.md||2016-07-06||btiffin||[r174] add some clarity to tl;dr portion|
The main source code repositories for GnuCOBOL on SourceForge use Subversion,
svn for short. To take part as a contributing member you will need some
form of Subversion system. There is the main command line version and quite a
few graphical front ends for Subversion. TortoiseSVN comes recommended.
See http://subversion.apache.org/ for all the details.
(too long; didn't read)
Install an svn client, then
svn checkout --username=sfuser svn+ssh://firstname.lastname@example.org/p/open-cobol/contrib/ workspace
where sfuser is your SourceForge userid, and workspace is your preferred local
Create a new working directory under
<workspace>/trunk/samples (for instance
localproject) or use the name assigned by Simon. He'll drop you a note when
you get write permissions on where the best place in the structure to place
your contribution, and the sub-directory may already be in place when you do
your initial checkout.
svn add workspace/trunk/samples/<localproject>
Work away at the next big thing, adding any newfiles with
svn add workspace/trunk/samples/<localproject>/<localfile>
It might be
tools instead of
samples depending on the type of
Then, when ready to share, update to current, just in case
svn update svn status
to see if you have missed marking any files for shared revision control.
Then make the commitment.
svn commit -m "commit message"
Keep up to date with
when your current working directory is
For most GNU/Linux systems, all you will need to do is install the package.
sudo apt-get install subversion
sudo yum install subversion
other systems will use different package commands, but all are similar and the
package is almost always called
For GNU/Linux, and GnuCOBOL programming in general, the command line is
For a graphical front-end, in particular Windows, TortoiseSVN is recommended,
but there are other options as well.
For a GNU/Linux gui, there is a few choices,
kdesvn if your desktop is KDE
based, or NautilusSVN for those that use Nautilus with GNOME. A quick bing on
google for "SVN client" is likely the easiest way of finding a client program
that suits your particular tastes and work habits.
Anyone can checkout the tree for local use, this is what it is being built for.
Contributors will need to have write permissions provided by the GnuCOBOL
management team, Simon Sobisch is in charge of the keys for this. Drop a note
on the GnuCOBOL forums at
and we'll get you all setup to contribute.
GnuCOBOL is a GNU free software project. The compiler is licensed under the
GPL version 3 (or greater), with the libcob runtime licensed under the LGPL 3
The compiler proper has had legal documents signed by all contributing
developers to place copyrights under the ownership of the Free Software
contrib/ tree has less obligation (you will keep copyrights) the
project still needs to use GPL compatible or other free software licensing for
these contributions. Contributions must have an explicit licensing notice to
be accepted. We recommend the GNU General Public License, GPL or LGPL version
3 (or greater), but will accept other licensing, at author discretion. It's
your software source, and you are free to choose, but the choice still needs to
be free software compatible. The whole point of the
contrib/ tree is the
sharing of free COBOL software for use with GnuCOBOL or other COBOL compiler
Each contribution will be vetted by other members of the project. Any security
concerns or other issues raised must be immediately addressed by the
contributing author, or the entry may be removed without warning, and without
svn is the main shell command.
Most people will not need to worry about
svnadmin for contributing, as the
repository is already setup and well managed.
svn help provides detailed help on all of the svn sub-commands, and there are
quite a few, but for normal day to day operations, most users will get by
knowing three or four main svn keywords.
First you need a working directory. That starts with a checkout of the
existing GnuCOBOL contrib/ tree.
SourceForge helps out here, as it gives the command to use for both ReadOnly
and ReadWrite permissions.
Visit https://sourceforge.net/p/open-cobol/contrib/HEAD/tree/ and near the top
middle of the web page there is options that show RW RO and HTTP command
options. Copy'n'paste a RO or RW command into a terminal to get a working
copy. Or follow the sequence required for your graphical client.
svn checkout svn://svn.code.sf.net/p/open-cobol/contrib/ open-cobol-contrib
is the normal ReadOnly command that is shown. This will create a working copy
under your current working directory called
open-cobol-contrib. You should
change that last part to suit tastes.
This author uses
prompt$ cd ~/wip/contrib
to hold a local working copy of the contributions tree, but that is up to you,
and has no effect on anyone outside of your local machine. In line with SVN
common practice, there are then sub-directories for
branches tags trunk
Most of the work for contributions occurs in
trunk/ is divided up (currently) with the following top levels
copyfiles esql GNU-Manuals ipc README samples tools
And most of the work here occurs in
tools/. For most
contributions, it is usually self evident which sub-directory to start in, but
talk with Simon and discuss any issues if the contribution doesn't seem to fit
in with the current tree structure.
samples/ each developer will create a new working
directory that reflects the name of the particular entry. For example,
contrib/trunk/samples/tools/prothsearch/ for a set of COBOL sources that
support Proth Prime searches. Within
prothsearch/, Lazlo created a
readme.txt that shows up on the SourceForge web pages all nicely formatted,
along with a sample
win_compile.bat to demonstrate the
tectonics for building the program. And the sources, as
prothtest.cob and a supporting
smallprimes.cpy copy book.
Within any particular working directory, a developer is free to choose a
comfortable structure, but there should be a readme along with some
instructions on how to go about building the software.
After you have the structure in place,
svn needs to be told that you wish to
track changes and to share. From
svn add prothsearch
would add all of the files in Lazlo's contribution, as add is recursive. You
may wish to pick and choose each file separately, if you have temporary build
files that don't need or should not be under revision control, .o compiler
outputs, for instance. But try and not miss any files, or they won't be
distributed on check-in and people that pull from the repository won't see the
files or be able to properly build your contribution.
To keep in synch, use
This command pulls any changes in the master repository into your local repo.
Please note that SVN is a distributed revision control system. That means
there are three copies involved at any given time. The master repository
stored on SourceForge, a local repository, and your working copy. The local
repository is usally hidden in '.svn' subdirectories and any working files stay
svn is told to check them in for sharing with the master
Your local working copy is never overwritten by
svn until told to do so.
If you have made edits, and then do
svn update, your current working files
will not be overwritten by the copy held in the master repository. Nor will
anyone else see local changes until an
svn commit occurs.
As each developer usually has their own sub-directory, there is very little
chance of conflicting edits and very little need to worry about the
complexities involved with
But please note: if you make local changes to another developer's files, and
you have write permissions, when you do an
svn commit, it will also commit
the changes you made to the other developer's files. Be careful when making
local customizations, and if there is ever an accidental commit, you'll need
to read up on
Many thanks for contributing. Each entry, large or small, makes GnuCOBOL a