Question about Source Control

[Chris Angelico]

On Tue, Mar 18, 2014 at 12:06 AM, Frank Millman <frank at chagford.com> wrote:
> All my source code resides on an old Linux server, which I switch on in the
> morning and switch off at night, but otherwise hardly ever look at. It uses
> 'samba' to allow sharing with Windows, and 'nfs' to allow sharing with other
> Linux machines.
>
> I need to test my program on Windows and on Linux, so I run it from both at
> various times. On Windows I have a 'mapped drive' pointing to the source
> code. On Linux I use a third machine, running a recent Fedora, using nfs to
> mount a directory pointing to the source code. Obviously each machine has
> its own version of Python installed.
>
> I do my development on the Windows machine. I use TextPad, a simple text
> editor, which works fine for my purposes. It uses the mapped drive to point
> to the source code.
>
> So where should I install the SCM, and how should I set it up so that I can
> access the latest version from any machine?

First off: You can save yourself a huge amount of trouble now! Modern
source control systems are distributed (DVCS - Distributed Version
Control System), which means that you have a much simpler setup: every
machine that uses it has a full clone of the repository.

By the sound of it, you don't have any history at the moment, so I'll
assume you just start using either git or hg from where you are. The
first thing to do is to get a local copy of the current source tree.
I'd start with a Linux system, because everything seems to be easier
there...

$ cp -r /mnt/samba/whatever/some_project_name .

Then you just 'cd' into the project directory (which can be anywhere
local - I tend to have a whole pile of them directly in my home
directory, or the root directory on Windows, but you can put them
anywhere; on my Hackintosh, I use the Documents directory so I can
find it more easily), and type either:

$ git init
$ git add .
$ git commit -m'Initial commit'

or

$ hg init
$ hg add .
$ hg commit -m'Initial commit'

Voila! You now have a repository tracking all your current source code
for that project. Then you just set yourself up to pull and push
somewhere. The easiest way to do that is to designate somewhere as the
central repository and always push changes to there and pull changes
from there; that's not strictly necessary, but I do recommend it.
Andriy recommends bitbucket; I like github, but that (as the name
implies) requires that you use git rather than Mercurial. (I also find
that git is rather faster than hg at most tasks. On the flip side, hg
is said to be a lot easier to set up on Windows than git is. I've
never used hg on Windows, so I can't say, but git on Windows isn't
quite as easy as could be desired.) You can also set up your own local
server very easily - a good plan if you're moving big binaries around
(not usually what you'd call "source code", but perfectly acceptable;
I recently ripped out our shared folder document repository and
replaced it with git-managed files) or working with something highly
sensitive. But for an open-source project, it's easiest to host it
"out there" somewhere, and let someone else do the work.

After that, it's simply a matter of going through the "quick start"
tutorial for your preferred SCM and host, which will help you get
started with authentication, push/pull commands, etc etc etc. Source
control is something to get your head around, but once you've done
that (which you might already have done for the sake of some open
source project), everything else becomes easy. Shared folders are easy
to explain to someone ("you can access this from everywhere!"), but
git or hg gives you ever so much more for no extra effort ("not only
can you keep track of your files, you can go back in time to see
what's happened, keep track of different branches of development,
share it all with the world, get suggestions from the world...").
Start thinking in terms of "my files are in this repository" rather
than "my files are on this server", and have lots of clones of that
repository, all acting as peers. Life's way better that way :)

ChrisA