Developing from multiple different machines

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

Post Reply
edi
Forum Newbie
Posts: 2
Joined: Wed Nov 24, 2010 7:12 am

Developing from multiple different machines

Post by edi »

Hi All,

I'm going to be doing some development work over the next few months that I would like to be able to do from a desktop PC in the office running Windows but also from my home desktop running Ubuntu and also hopefully from my Ubuntu netbook as well.

It seems that keeping the files and database synchronised and the potential for differences in the Apache server configuration is going to be a bit of a headache.

My current thoughts are that using SQLLite for the database should mean that I can copy all the files around easily enough but are there any better solutions? Would using a PHP web host and downloading / uploading the files I need be a good idea? I could probably write a script to automate the upload process.

What would you guys do in this situation?
User avatar
Weirdan
Moderator
Posts: 5978
Joined: Mon Nov 03, 2003 6:13 pm
Location: Odessa, Ukraine

Re: Developing from multiple different machines

Post by Weirdan »

I'd look into two possible solutions:
  • Use version control system (well, you should be using it anyway). Git, bazaar, svn - whatever you fancy.
  • Use a file sync program - Dropbox, for example (free accounts limited to 2GB).
Doug G
Forum Contributor
Posts: 282
Joined: Sun Sep 09, 2007 6:27 pm

Re: Developing from multiple different machines

Post by Doug G »

Eclipse PDT is cross-platform and has cvs/svn support available. I used to use Eclipse to work on the same project from either windows or linux computers.

Keeping a database sync'd is a different problem. Generally you'd have a production database and a development database, you don't want to do any program development on a live DB. If you use a server db like mysql all your workstations can share the development database as long as they can reach the server over the network.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Re: Developing from multiple different machines

Post by alex.barylski »

1. Use SVN
2. Store config details (DB, SMTP, etc) in http.conf and bring them into local scope by assigning to define's or similar.
3. Look into SQLYog is has a database syncronization feature - Google PHP migrations as well

Use a editor such as Eclipse and store local copies for at least 7 days.

Setup a test and live environment on the same physical machine, so you can commit changes to the server from any of your desktops and test account.

Cheers,
Alex
User avatar
VladSun
DevNet Master
Posts: 4313
Joined: Wed Jun 27, 2007 9:44 am
Location: Sofia, Bulgaria

Re: Developing from multiple different machines

Post by VladSun »

There are 10 types of people in this world, those who understand binary and those who don't
edi
Forum Newbie
Posts: 2
Joined: Wed Nov 24, 2010 7:12 am

Re: Developing from multiple different machines

Post by edi »

Thanks for all the help guys, i'm going to do some investigation on your suggestions now and am confident that I'll get something good sorted out! :D
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Developing from multiple different machines

Post by josh »

Use SVN, not Git. Git is decentralized. I haven't used it myself but here's my understanding: So for example with Git you can make commits with no internet access, but by doing so you branch the code (which can require manual steps to merge that branch later) With SVN you must have internet access, but you will always be guaranteed to be working on the main trunk, and not a branch.
jarofgreen
Forum Commoner
Posts: 71
Joined: Sun Jul 11, 2010 12:40 pm

Re: Developing from multiple different machines

Post by jarofgreen »

Not quite how git works. It doesn't create a branch with every off-line commit.

Git is decentralised, but you'll find a very common useage case is to have 1 central repository that is the master, then working copies all pull or push to that. I've used it that way myself on a project where I would move between coding on a desktop to a laptop with no problems, and with no unwanted branches.

Just remember to update your working copy every time you start working. I forgot several times and had to merge - but that's easy.

For this project we used a repository on http://www.codebasehq.com/ for the central repository but there are zillions of options.

To answer the original question ...
Definitely use code versioning of some kind. If it's just a small 1-coder project then there is not much between svn, git and whatever but definitely use something.
josh
DevNet Master
Posts: 4872
Joined: Wed Feb 11, 2004 3:23 pm
Location: Palm beach, Florida

Re: Developing from multiple different machines

Post by josh »

jarofgreen wrote:Just remember to update your working copy every time you start working. I forgot several times and had to merge
Call it what you want, but you branched. The fact you can commit, without committing to mainline makes it a branch by definition. In SVN the conflicts are brought to your attention when you commit, not the next day. You have the ability to also do continuous integration. WIth Git, you can technically commit with no internet access, so its physically impossible to know for sure that your changes won't break some unit test your co-worker just wrote.

Read this thread if you disagree: viewtopic.php?f=6&t=108435

Keep in mind a LOT more can go wrong than just seeing a merge screen. Like seeing no merge screen, but introducing 100s of small, but major, hard to find bugs....
jarofgreen
Forum Commoner
Posts: 71
Joined: Sun Jul 11, 2010 12:40 pm

Re: Developing from multiple different machines

Post by jarofgreen »

This seems to be hinging on splitting hairs on the definition of commit vs commit/push, which I am far to tired to go into now.
josh wrote:Keep in mind a LOT more can go wrong than just seeing a merge screen. Like seeing no merge screen, but introducing 100s of small, but major, hard to find bugs....
The same is true in SVN, because if you commit code that does not directly conflict with an later update on the server it will let you. However it is still possible to introduce bugs that way. But that's one reason you have Continuous Integration, to catch such bugs.

Can I just clarify, you seem to be implying you can't do Continuous Integration with GIT, are you? Cos that's rubbish.

I read the thread. I agree that Branching has a cost in terms of time and maintenance, but I think the advantages outweigh the costs. Jenk has come up with a very opinionated development model which may suit his/her business, which is fine, but don't make the mistake of thinking that means everyone should use it.

If my boss came to me with a urgent bug in software I had released months ago, and I told him I refused to fix it and he would just have to update the client with the latest code, including some just-done not-tested not-acceptance-tested not-approved changes, he would not be happy.
jarofgreen
Forum Commoner
Posts: 71
Joined: Sun Jul 11, 2010 12:40 pm

Re: Developing from multiple different machines

Post by jarofgreen »

Ok, I think one thing is that you are comparing "svn commit" to "git commit". Don't. Mentally compare "svn commit" to "git commit/git push", as that is functionally the same. If you want, you could even code up a script to push automatically on each commit.

Also about committing off-line, depending or your circumstances that can be life saver. If you all work in an office with access to a central server it's not important, if you have staffers who work externally all over the place it's great. Again, it depends on your circumstances.

I'm not saying Git is better, or don't use SVN - in fact I use more SVN that GIT at the moment myself. Just saying it's a very good choice, and don't write it off.
Post Reply