On Wed, Mar 19, 2014 at 5:41 PM, Frank Millman <fr...@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 -- https://mail.python.org/mailman/listinfo/python-list
