Where do you keep your project repositories
Moderator: General Moderators
Where do you keep your project repositories
Probably everyone here has many projects, work and personal. What I wondered: where do you keep the repositories? For open source (collaborative) projects, I think googlecode, sourceforge and github are good places. But what about personal or work related projects you don't want to share with the whole world. Do you keep them local on your computer, set up a svn repo on a server?
I have svn running, and am able to create a folder /repositories or something in my user folder. And then do a checkout to the folder in my local server to test the project. Are there better ways then this?
I have svn running, and am able to create a folder /repositories or something in my user folder. And then do a checkout to the folder in my local server to test the project. Are there better ways then this?
Re: Where do you keep your project repositories
I just have them in a folder on my computer. It's backed up by Time Machine.
Files at work are stored on my network drive, which is also backed up.
Files at work are stored on my network drive, which is also backed up.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
Re: Where do you keep your project repositories
I just have a projects folder, and use Git(better than SVN in my opinion) for source control.
Re: Where do you keep your project repositories
@pickle: so your projects are not in version control?
@Cirdan: do you use Git locally?
The reason I want to know about others' setups is because I'm looking in ways to improve the way I have set up my files and projects.
As it is now it looks something like:
So as you see in the documents folder are my normal files, with one folder for the projects. Here I keep all project related documents, from legal documents, documentation, small snippets of code, etc etc
Now the sites folder is where the local server runs. There the development version of the project runs. When it's time to put the project live, I copy the files from the site folder to the server.
However, what's missing in this is subversion control. And when it comes to updating a live project it gets messy. First make a backup of files and db from the live server to, for example
/documents/projects/someproject/backups/2009-08-06/
Then copy the changed files from /sites/someproject/ to the live server. Check if everything is ok. If not, go back to the backups and restore the files. Etc It all gets messy fast, because you don't always have an exact replica of the project locally and remote. You need special configuration files locally for example.
Now that I have worked with a few projects using a central subversion server, all these problems fade away (most of them anyway). Checkout the project. Change locally. Update. Do an export to the live site.
Actually, its too bad working with subversion is still quite technical, otherwise I would put all my files in a repository like place. How many times have you not emailed back and forth word documents with other people, giving those docs names like "proposal-version-6b-mike", writing instructions in the email to let the other know what has changed, etc. getting confused about who was working on what and when.
The tools for a better and more integrated way of working are there, but just not yet good enough to be useful in a broader way.
@Cirdan: do you use Git locally?
The reason I want to know about others' setups is because I'm looking in ways to improve the way I have set up my files and projects.
As it is now it looks something like:
Code: Select all
/documents/
/documents/projects/
/documents/projects/someproject/
/pictures/
/../
/sites/
/sites/someproject/Now the sites folder is where the local server runs. There the development version of the project runs. When it's time to put the project live, I copy the files from the site folder to the server.
However, what's missing in this is subversion control. And when it comes to updating a live project it gets messy. First make a backup of files and db from the live server to, for example
/documents/projects/someproject/backups/2009-08-06/
Then copy the changed files from /sites/someproject/ to the live server. Check if everything is ok. If not, go back to the backups and restore the files. Etc It all gets messy fast, because you don't always have an exact replica of the project locally and remote. You need special configuration files locally for example.
Now that I have worked with a few projects using a central subversion server, all these problems fade away (most of them anyway). Checkout the project. Change locally. Update. Do an export to the live site.
Actually, its too bad working with subversion is still quite technical, otherwise I would put all my files in a repository like place. How many times have you not emailed back and forth word documents with other people, giving those docs names like "proposal-version-6b-mike", writing instructions in the email to let the other know what has changed, etc. getting confused about who was working on what and when.
The tools for a better and more integrated way of working are there, but just not yet good enough to be useful in a broader way.
Re: Where do you keep your project repositories
Yea I just use it locally. I really like how Git doesn't require a server to be running so it makes it super easy to backup. Everything is just self contained in the project's directory.
Re: Where do you keep your project repositories
/home/username/repos
Seems to be a great home for them
Seems to be a great home for them
Re: Where do you keep your project repositories
yeah, I just created the same.astions wrote:/home/username/repos
Seems to be a great home for them
Re: Where do you keep your project repositories
No, no version control. I'm the only one working on them & they usually have an audience of < 100 people, so it's not worth the hassle.
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
Re: Where do you keep your project repositories
But even if you're the only one, you can still use subversion. The thing with not using subversion is that if I change a couple of things, I don't know if I can reverse everything. Or if I want to test a bigger change, I don't have to copy everything to /project-testcopy/, make the changes, and then somehow merge everything back manuallypickle wrote:No, no version control. I'm the only one working on them & they usually have an audience of < 100 people, so it's not worth the hassle.