Question about Source Control

[Chris Angelico]

On Wed, Mar 19, 2014 at 5:41 PM, Frank Millman <frank at chagford.com> wrote:
> I have decided to stick with Mercurial, simply because that is what I used
> in my previous attempt and I felt comfortable with it.

That's the best reason for choosing, really.
https://github.com/Rosuav/Gypsum/commit/0f973
> Also I believe that
> Python itself uses it, so if it is good enough for them ...

Mercurial is used by a good number of high-profile projects. You're
probably thinking of CPython, the implementation, but
Python-the-language is built on top of Mercurial too, with such as the
PEP repo and the web site (although I understand the latest version of
the web site is managed in git). Both git and hg are used by plenty of
solid projects, including the Linux kernel (git's original purpose),
themselves (git's development is managed in git, hg's is managed in
hg), and plenty of other big projects. This is one reason why I always
push people to either of those two, rather than to an unknown or
proprietary system that might have problems.

> I realise now that my initial problem had nothing to do with SCM/VCS, and
> everything to do with my lack of knowledge of basic networking protocols. As
> I understand it now, if I want to share the repository over a network, I can
> choose between SSH and HTTP. I like the following quote from Joel Spolsky -
>
> "The quick-and-dirty way to make a central repository is to use Mercurial's
> built in web-server. ... I'm going to configure the server to allow anybody
> in the world to do anything they want to it. ... Needless to say, this is
> rather unsafe, but if you're on a nice protected LAN at work and there's a
> good firewall and you trust everybody on your LAN, this is reasonably OK."
>
> This describes my situation well, so to keep things simple I will start with
> this.

Yep! People complain loudly about the insecurity of protocols like
FTP, but properly-firewalled networks with all members trusted are
more common than you might think - all you need is a basic home-grade
NAT router and a sysadmin whose competence exceeds the sensitivity of
your content.

> To recap my basic setup, I have machine A which holds the source directory,
> machine B which is used to edit the program, and machines B and C which are
> both used to run the program.
>
> Initially, to prove that I understand the concept, I propose to install
> Mercurial on all three machines. Machine A will hold the central repository,
> which I will clone onto machines B and C. After editing on B, I will 'push'
> to A, and then from C 'pull' from A to get the latest version.

Right. That's a nice standard setup. There'll be plenty of tutorials
that can walk you through setting that up. (Don't forget, btw, that
most Linux distributions will include Mercurial - just "apt-get
install mercurial" or "yum install mercurial".)

> If this works, I will simplify it to make my life easier. My first thought
> was to remove the clone from machine C and set up an nfs share pointing to
> the working directory on machine A, so I don't need the 'pull' step. Then I
> thought, why not just point to the working directory on machine B, so then I
> can test the changes on C directly, without even having to 'push'. I realise
> that this is defeating the object of version control, but I think it makes
> sense. I will still use version control to maintain a full history of the
> project on machine A.

It doesn't defeat the object of version control as long as you always
make logical, conceptual commits. However, it does introduce a
dependency (the NFS share) and the associated messes of file locking
and so on, so I personally would prefer to deploy a file-transfer
system, maybe like the one I described earlier, or maybe something
more like FTP. But do whatever makes sense for you.

> Over the last few years I have frequently 'trashed' whole sections
> of my code and rewritten them, which I suspect would not endear me to
> someone attempting to collaborate with me. However, the broad framework is
> starting to settle down now, so I am starting to think about putting it out
> there.

That's not in itself a problem. This commit made quite a few changes,
all at once:

https://github.com/Rosuav/Gypsum/commit/0f973

It does mean that anyone who's collaborating with you will need to
keep a close eye on what goes on, but that's true of any fast-moving
project. As things get more stable, it'll be easier to join in.

ChrisA