Help with working on same webproject on different machines

[ibbadib]

Hey there,

 

I have a Ubuntu install on my desktop, and windows 8.1 on my laptop.

 

I also set up a Debian webserver in my house on an old laptop. I am a total noob when it comes to all of this server stuff.

 

 

I want to:

 

1. Work on the same projects on different machines, and having the files automatically update from the laptop to the desktop and vice versa. I would like to use the server for this if possible.

2. Use the server for testing the webpages.

 

 

Problems and questions:

 

3. I figured I would just set up a workspace on the server, and use that location on both machines, but I don't know how.

4. As I have made the server global, so I can use it from school, are there any security measures I have to take?

 

EDIT: How do I open the servers GUI from my desktop, to configure it? Doing stuff through the terminal is getting tediuos.

 

 

Thank you

:-)

[madknight3]

If you don't need real time syncing, I would use version control software like Subversion or Git to handle everything.

 

If you do need real time syncing, you might be able to have a general cloud service like Google Drive or Dropbox take care of it for you.

[MrBlank]

+1 for version control. It's super useful to get into the habit of using version control for all of your projects. I recommend git. quick guide here: http://rogerdudler.github.io/git-guide/ and you can host repositories externally with free services such as bitbucket.

[ibbadib]

+1 for version control. It's super useful to get into the habit of using version control for all of your projects. I recommend git. quick guide here: http://rogerdudler.github.io/git-guide/ and you can host repositories externally with free services such as bitbucket.

I've tried to read about Git, but I don't really understand what it Does.

Do you know an easy to understand article or something?

Thanks

[madknight3]

I've tried to read about Git, but I don't really understand what it Does.

Do you know an easy to understand article or something?

Thanks

 

I've really gotta get around to using Git myself at some point. I've only ever used subversion.

 

I expect these are a couple good options for learning (take advantage of their free trials)

- Lynda.com Git Essential Training   (support Linus Media Group by signing up with wanshow or techquickie)

- Treehouse Git Basics

[Nuluvius]

Git and Mercurial are the big players in distributed source control. They are roughly equivalent, choosing one over the other is personal preference before we get into any arguments about which is better. That said I happen to prefer Git and have been using it just as long as I have the other two big names (Mercurial & Subversion). I think it's got a slightly better community in that there seem to be more plugins, projects and generally better support - for instance nice little things like integration into Visual Studio by way of both tools and margin + solution icons/colourization.

 

A comparison of all three and a little bit about the difference between centralized (like Subversion) and distributed.

 

Using source control is basically invaluable and one should pity the developer who fails to see this. A very general overview of it; you have access to your code base at every point in time as it evolves, assuming you make granular enough commits. You are free to go back, forward and sideways via branching. You may bisect (to quickly track down bugs), patch, shelve, pull request (useful for code reviews in big teams/necessary even in open source) as well as nest repositories #n deep to mention a few of the capabilities at ones disposal.

 

There are many opinions on best practices about committing and branching. I prefer the pragmatic as always Commit as granular as possible and as frequently as it makes sense to i.e. you change/implement a class or small unit of functionality then you commit. Keep a stable branch (usually the default because in some source control systems such as Mercurial that's what a user gets when cloning) and develop (introduce instability) in other branches, when it's done, close it and merge it back in to keep the branch count down. Always pull before commit and push in distributed source control - it will help with the inevitable merge ambushes. I also generally tend to prefer the command line over GUI tools, but there is value in good GUI tools for your source control as they can help visualize and deal with complex branching and operations.

 

In short, it's a game changer - but it should always be combined with a backup policy. Unless it's cloud based then it's not your problem. That said I'd still be inclined to keep a backup.

[SSL]

Just use Dropbox or Google Drive, especially if using the terminal is "tedious". You probably won't benefit from using verison control.

[MrBucket101]

Just use Dropbox or Google Drive, especially if using the terminal is "tedious". You probably won't benefit from using verison control.

Or take it a step further and use bittorrent sync

[ibbadib]

Git and Mercurial are the big players in distributed source control. They are roughly equivalent, choosing one over the other is personal preference before we get into any arguments about which is better. That said I happen to prefer Git and have been using it just as long as I have the other two big names (Mercurial & Subversion). I think it's got a slightly better community in that there seem to be more plugins, projects and generally better support - for instance nice little things like integration into Visual Studio by way of both tools and margin + solution icons/colourization.

A comparison of all three and a little bit about the difference between centralized (like Subversion) and distributed.

Using source control is basically invaluable and one should pity the developer who fails to see this. A very general overview of it; you have access to your code base at every point in time as it evolves, assuming you make granular enough commits. You are free to go back, forward and sideways via branching. You may bisect (to quickly track down bugs), patch, shelve, pull request (useful for code reviews in big teams/necessary even in open source) as well as nest repositories #n deep to mention a few of the capabilities at ones disposal.

There are many opinions on best practices about committing and branching. I prefer the pragmatic as always Commit as granular as possible and as frequently as it makes sense to i.e. you change/implement a class or small unit of functionality then you commit. Keep a stable branch (usually the default because in some source control systems such as Mercurial that's what a user gets when cloning) and develop (introduce instability) in other branches, when it's done, close it and merge it back in to keep the branch count down. Always pull before commit and push in distributed source control - it will help with the inevitable merge ambushes. I also generally tend to prefer the command line over GUI tools, but there is value in good GUI tools for your source control as they can help visualize and deal with complex branching and operations.

In short, it's a game changer - but it should always be combined with a backup policy. Unless it's cloud based then it's not your problem. That said I'd still be inclined to keep a backup.

I'll stick with something simpler for now. The server is only experimental.

And try to use something like Filezilla to upload to the server.

Just use Dropbox or Google Drive, especially if using the terminal is "tedious". You probably won't benefit from using verison control.

Yeah. Thanks