Hi all,
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL).
But, I want to see if CVS, or maybe even a forge script (like in offerforge) could benefit met. Most of the time when we make changes to the code, we simply update the version, from say 1.2.2 to 1.2.3 and write the changes to a basic changelog, which in our case is a simple text file calles changelog.txt
But, how could I benefit from a CVS, ir similar system? And what would be best for this environment? I installed CVS on my CentOS server, but it seems that it's not just a matter of creating a tree and dumping code. I'm not too worried about multiple users at this stage. All our coding is currently stored on a CentOS 5.4 Samba server, so we can access to the code from either a Windows or Linux PC. Do I need anything more?
I started using eclipse+PHP a few months ago and I don't really use it to its full potential, so I'm sure I could benefit from it more.
So, the question is, what is a good recommended setup to go with? Web based access to all the files would be nice, then we could access it from outside the LAN on HTTPS. And how do I use it to my benefit? For example, clientA wants to make changes to Project1. Now I have a Project1 in the CVS tree (is this the right terminology?), and make changes to file contacts.php - what now? Do I need to create a subfolder called 1.2.2 (for example), and add only the updated file in this folder, or do I copy the whole Project into the new folder?
2 weeks down the line I need to make changes to 8 files, what do I do now?
Does this make sense? I realize it could be beneficial to keep older files, but how does one structure it?
From: Rudi Ahlers Rudi@SoftDux.com
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL). But, I want to see if CVS, or maybe even a forge script (like in offerforge) could benefit met. Most of the time when we make changes to the code, we simply update the version, from say 1.2.2 to 1.2.3 and write the changes to a basic changelog, which in our case is a simple text file calles changelog.txt
Check subversion: http://subversion.apache.org/ They have a quite good documentation: http://svnbook.red-bean.com/
It is nice to be able to go back to n previous version in case you realised that the newer versions messed up everything... people can work in parallel on different versions (production/dev, 1.x, 2.x...), etc...
JD
Greetings,
On Thu, Feb 11, 2010 at 4:14 PM, Rudi Ahlers Rudi@softdux.com wrote:
Hi all,
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL).
But, I want to see if CVS, or maybe even a forge script (like in offerforge) could benefit met. Most of the time when we make changes to the code, we simply update the version, from say 1.2.2 to 1.2.3 and write the changes to a basic changelog, which in our case is a simple text file calles changelog.txt
But, how could I benefit from a CVS, ir similar system? And what would be best for this environment? I installed CVS on my CentOS server, but it seems that it's not just a matter of creating a tree and dumping code. I'm not too worried about multiple users at this stage. All our coding is currently stored on a CentOS 5.4 Samba server, so we can access to the code from either a Windows or Linux PC. Do I need anything more?
I started using eclipse+PHP a few months ago and I don't really use it to its full potential, so I'm sure I could benefit from it more.
So, the question is, what is a good recommended setup to go with? Web based access to all the files would be nice, then we could access it from outside the LAN on HTTPS. And how do I use it to my benefit? For example, clientA wants to make changes to Project1. Now I have a Project1 in the CVS tree (is this the right terminology?), and make changes to file contacts.php - what now? Do I need to create a subfolder called 1.2.2 (for example), and add only the updated file in this folder, or do I copy the whole Project into the new folder?
2 weeks down the line I need to make changes to 8 files, what do I do now?
Does this make sense? I realize it could be beneficial to keep older files, but how does one structure it?
+1
Though I have got SVN with ACL and all that going at couple of places, I have never come around to use it. I have heard elsewhere that Sysadmins use that for config file and the such.
Also I was wondering if we can have some tutorials around centos like the excellent typical use case examples of Samba.
I will try and contribute what I can in terms of knowledge, experience anecdotes and the such.
Perhaps in the wiki?
For example multi location scenario, cases of some server within and some hosted with ISP etc. Suggested infrastructure components for various scenarios like development/ distributed development, web based app, fixed and adsl mixure of client scenarios etc. etc. etc.
Hope I am made myself somewhat clear...
Apologies for highjacking this thread...
Regards,
Rajagopal
On 11 February 2010 10:44, Rudi Ahlers Rudi@softdux.com wrote:
Hi all,
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL).
[ snip ]
If you're just getting into source code control, then I'd strongly recommend bypassing "legacy" systems like CVS and Subversion. Most of the world seems to be moving to distributed system like git (http://en.wikipedia.org/wiki/Git_%28software%29).
You can host your own git repositories, or you can use a third party hosting service like github (http://github.com/).
I moved all of my projects from Subversion to github (http://github.com/davorg/) a year ago and I'm very happy with it.
Cheers,
Dave...
On Thu, Feb 11, 2010 at 1:09 PM, Dave Cross davorg@gmail.com wrote:
On 11 February 2010 10:44, Rudi Ahlers Rudi@softdux.com wrote:
Hi all,
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably
cause
most of our projects don't really require that we need to keep a history
of
what has changed. i.e. a client wants to change something on their
website,
and we change it, whether it's cosmetics or code (normally PHP & MySQL).
[ snip ]
If you're just getting into source code control, then I'd strongly recommend bypassing "legacy" systems like CVS and Subversion. Most of the world seems to be moving to distributed system like git (http://en.wikipedia.org/wiki/Git_%28software%29).
You can host your own git repositories, or you can use a third party hosting service like github (http://github.com/).
I moved all of my projects from Subversion to github (http://github.com/davorg/) a year ago and I'm very happy with it.
Cheers,
Dave... _______________________________________________
Thanx Dave, I'll check it out. Isn't GIT more aimed at software, than web development projects?
P.S. I don't have a problem hosting my own code, we already have all the infrastructure in place :)
On 11 February 2010 11:26, Rudi Ahlers rudiahlers@gmail.com wrote:
On Thu, Feb 11, 2010 at 1:09 PM, Dave Cross davorg@gmail.com wrote:
On 11 February 2010 10:44, Rudi Ahlers Rudi@softdux.com wrote:
Hi all,
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL).
[ snip ]
If you're just getting into source code control, then I'd strongly recommend bypassing "legacy" systems like CVS and Subversion. Most of the world seems to be moving to distributed system like git (http://en.wikipedia.org/wiki/Git_%28software%29).
You can host your own git repositories, or you can use a third party hosting service like github (http://github.com/).
I moved all of my projects from Subversion to github (http://github.com/davorg/) a year ago and I'm very happy with it.
Thanx Dave, I'll check it out. Isn't GIT more aimed at software, than web development projects?
P.S. I don't have a problem hosting my own code, we already have all the infrastructure in place :)
Git can be used to store any data that you want to keep different versions of.
Dave...
From: Rudi Ahlers rudiahlers@gmail.com
Thanx Dave, I'll check it out. Isn't GIT more aimed at software, than web development projects? P.S. I don't have a problem hosting my own code, we already have all the infrastructure in place :)
Maybe check http://git.wiki.kernel.org/index.php/GitSvnComparison I would try both and see which one fits my needs the best...
JD
Rudi Ahlers wrote:
On Thu, Feb 11, 2010 at 1:09 PM, Dave Cross <davorg@gmail.com mailto:davorg@gmail.com> wrote:
On 11 February 2010 10:44, Rudi Ahlers <Rudi@softdux.com <mailto:Rudi@softdux.com>> wrote: > Hi all, > > I would like some suggestion on this matter please. I have never bothered > using any code repositories / version control systems for our web > development project, many cause I didn't know any better, and probably cause > most of our projects don't really require that we need to keep a history of > what has changed. i.e. a client wants to change something on their website, > and we change it, whether it's cosmetics or code (normally PHP & MySQL). [ snip ] If you're just getting into source code control, then I'd strongly recommend bypassing "legacy" systems like CVS and Subversion. Most of the world seems to be moving to distributed system like git (http://en.wikipedia.org/wiki/Git_%28software%29). You can host your own git repositories, or you can use a third party hosting service like github (http://github.com/). I moved all of my projects from Subversion to github (http://github.com/davorg/) a year ago and I'm very happy with it. Cheers, Dave... _______________________________________________Thanx Dave, I'll check it out. Isn't GIT more aimed at software, than web development projects?
P.S. I don't have a problem hosting my own code, we already have all the infrastructure in place :)
The philosophical difference between git and subversion is that subversion by design has only one central repository. You can branch the work there if you want to maintain different versions simultaneously, but the working copies where you make changes don't store the history or multiple versions. With git you can clone the whole repository and make changes locally and it is optional whether the central (if there is such a thing) repository accepts your changes. Subversion is good if you want central control and have good network connections to all places where you edit. Git is better if some people need to edit offline or people want to be able to fork the work and never commit back to the original repository. If you use subversion, you probably want to start with the current version packaged in rpmforge instead of the ancient one in stock centos.
Greetings,
On Thu, Feb 11, 2010 at 4:14 PM, Rudi Ahlers Rudi@softdux.com wrote:
Hi all,
and perhaps Subtrain will help to go one step further
http://www.polarion.com/downloads/svn.php
Regards
Rajagopal
SVN. Easy to setup, and the docs are excellent. I'm using it all the time.
I second that: it the OP is not that familiar with version control systems, Subversion is more intuitive and answers will be easy to find on the web.
Le 10-02-11 à 09:05, Mathieu Baudier a écrit :
SVN. Easy to setup, and the docs are excellent. I'm using it all the time.
I second that: it the OP is not that familiar with version control systems, Subversion is more intuitive and answers will be easy to find on the web.
And more client tools too, including the ones that you can install in Eclipse.
The one other tidbit that I'd add is ... experiment! Don't let your first try at setting up a repository be your production setup.
Try different repository layouts. The online subversion book walks you through the issues, but I'd caution against making a decision without trying stuff out.
Create your repo (I use Subversion, but that's no knock against Git or Darcs or Mercurial or ...). Check out or clone a copy. Edit some files. Rearrange directories. Commit the changes. Rinse, lather, repeat -- several times.
Ask yourself if the layout is good, if the repository workflow dovetails with the way you work, if the client-side tools work well with the various operating systems in your environment.
If you'll rely on a central, official repository, figure out a backup strategy.
It's good to figure out a template for commit messages: what information needs to be provided to document the "why" of changes. There are few things more annoying than an empty or meaningless commit message.
Finally, if your repository goes hand-in-hand with a lot of meta-information like documentation, trouble tickets, milestones, or things like screenshots, think about associating your repository with a wiki like Trac:
Rudi Ahlers wrote:
I would like some suggestion on this matter please. I have never bothered using any code repositories / version control systems for our web development project, many cause I didn't know any better, and probably cause most of our projects don't really require that we need to keep a history of what has changed. i.e. a client wants to change something on their website, and we change it, whether it's cosmetics or code (normally PHP & MySQL).
But, I want to see if CVS, or maybe even a forge script (like in offerforge) could benefit met. Most of the time when we make changes to the code, we simply update the version, from say 1.2.2 to 1.2.3 and write the changes to a basic changelog, which in our case is a simple text file calles changelog.txt
But, how could I benefit from a CVS, ir similar system? And what would be best for this environment? I installed CVS on my CentOS server, but it seems that it's not just a matter of creating a tree and dumping code. I'm not too worried about multiple users at this stage. All our coding is currently stored on a CentOS 5.4 Samba server, so we can access to the code from either a Windows or Linux PC. Do I need anything more?
I'd use subversion rather than cvs, but the concepts are mostly similar. Create a repository, import your existing file tree (or several if you want to break it into projects at directory levels. Then check out a working copy somewhere else. Once you are sure that works, delete (or move) your original copy and check out a working copy in its place (this might be your actual web server tree or a staging copy that you rsync to the real server(s). From then on, you always edit in working copies and commit the changes back to the repository. Many working copies can be checked out at once, and an 'update' command will bring them up to the current repository version so it is easy for many people to share work. You can use subversion's own server protocol or the mod_dav_svn module for apache for access over http(s).
I started using eclipse+PHP a few months ago and I don't really use it to its full potential, so I'm sure I could benefit from it more.
With eclipse, you can use the subclipse module for GUI access to the subversion features. If you work from windows the tortisesvn program adds it to windows explorer.
So, the question is, what is a good recommended setup to go with? Web based access to all the files would be nice, then we could access it from outside the LAN on HTTPS. And how do I use it to my benefit? For example, clientA wants to make changes to Project1. Now I have a Project1 in the CVS tree (is this the right terminology?), and make changes to file contacts.php - what now? Do I need to create a subfolder called 1.2.2 (for example), and add only the updated file in this folder, or do I copy the whole Project into the new folder?
You can control access by path - or have separate repositories per client/site. Normally everyone just commits work to the repository as they go, then when the changes are ready you update the site to that revision - perhaps through a staging/test process.
2 weeks down the line I need to make changes to 8 files, what do I do now?
Edit in a working copy, commit, update in the master copy.
Does this make sense? I realize it could be beneficial to keep older files, but how does one structure it?
History is kept automatically. Every commit makes a revision number and you can check out (or update to) any revision ever committed. If you want to make big changes and be able to edit different versions simultaneously you can make branch copies. If you want what appear to be snapshot copies with your own naming convention you can make tag copies. This is all covered pretty well in the subversion documentation and the only thing that takes any thought is how the repository relates to the active site. You might be able to make the live files a working copy and manage it directly with updates to current or a specified revision number. Or you may want to do that in a staging area, perhaps with a way to preview the changes, then use rsync (which has a -C option to skip CVS or subversion metadata) to push to the production location(s).
-
Dave Cross -
John Doe -
Les Mikesell -
Mathieu Baudier -
Niki Kovacs -
Pascal Robert -
Paul Heinlein -
Rajagopal Swaminathan -
Rudi Ahlers -
Rudi Ahlers