When you install TortoiseSVN you need to tick the "command line tools" option if you want to use the command line as well as the GUI.

Its fine to use SourceForge but initially you should first "learn" the basics using a simple filesystem repository.

Some tips:

- As you are programming in linux and windows, learn how to control the line endings in the repository and in your working copies using svn:eol-style= native.

   see

   http://svnbook.red-bean.com/en/1.1/ch07 … sect-2.3.5

- learn how to include the current version number as a comment in each file (if you want).

- Don't rush things, especially when you get a conflict message when your "working base" becomes out of date due to other users' commits. (The "other" user could be someone else or you working on your other operating system).

- Do use sensible commit messages.

I've installed Subversion and TortoiseSVN, and I'm learning how to use them.

I am going to try to use SourceForge for my repository.
I don't yet know how to use that either.

Does all the above seem sensible?
I'll need access to my repository using Linux on one laptop and Windows on another.

I'll appreciate any useful tips.
"RtFM" I know already!
---
J.

I use the excellent TortoiseSVN client for Windows and I use the command line in linux.

http://tortoisesvn.net/

It comes with TortoiseDiff for looking at file differences (between versions) but also allows you to use other tools if you wish.

In the office the repository is stored on a linux workstation which runs a server program to allow access to the repository from the client machines (Windows PCs and linux workstations).

At home, I run a Subversion server directly on my Synology NAS drive on my local LAN so I can access my repositories from any computer on the network (there are 3) and from windows and linux. I am the only programmer using these repositories but I still use version control to help track the changes I make.

There is also a Git server for the NAS and TortoiseGit but I haven't tried them.

I would say stick with Subversion unless you need to work with an existing project that is using Git.

I've used quite a few over the years.   I've basically settled on using two, either Subversion or Git.  Subversion is arguably the simpler of the two.  On single-developer projects it works out nicely because no "server" is actually necessary (although Git  doesn't need one either, but  anyway...).   Subversion is simple because it basically tracks commits to your central repository (this can be a directory on your system, not necessarily a server) by number in sequential order.  Additionally, on Windows, TortoiseSVN is a very powerful Subversion client that can eliminate any need for command-line use.

Git is a form of distributed version control, but, for a single developer, this distinction might not be overly important.  Git is, in my opinion, more powerful because "branching" the code is drastically simpler.  Branching is central to the Git workflow.  Basically, you'd create a local branch, make your changes, merge them back  to the "master" branch, and commit them.  Git's learning curve is a bit steeper than Subversion, so it might be better to start with Subversion.  Additionally, Git's tracking of your code via hashes rather than a simple, sequential number can be intimidating at first. 

There are some great books available for free for both these solutions:

Subversion: Version Control with Subversion

Git: Pro Git

I wouldn't suggest any other version control systems at this time.  Subversion was designed to be a "better" CVS, so I would suggest avoiding CVS.  Mercurial  is often offered as an alternative to Git, but I've never been a particular fan of it.  There are a few proprietary ones, but I think maybe Perforce is the only one that I've actually enjoyed using.

If it makes any difference, Simply Fortran itself is developed using Git as source control, but it had previously used Subversion.

Simply Fortran doesn't directly integrate any version control system, incidentally, because we've never had any users request that feature.

I don't have enough spare time to install several of them, learn how to use each one (which looks like quite a lot to assimilate), then try each one for a few weeks.  I'd therefore really appreciate a very brief list from contributors to this forum, of the best known VCSs, and what their pluses and minuses seem to be.  I plan to rely on what I read here to help me choose what will work best for my particular purposes.
----
John