Join 150,149 Programmers for FREE! Get instant access to thousands of experts, tutorials, code snippets, and more! There are 2,346 people online right now. Registration is fast and FREE... Join Now!
I am working with others on some large webdev projects. The files, as of right now, are located on a server. But, we now want to implement some sort of version control system.
I have looked at TortoiseSVN and a few other, but can not find one that suits our needs.
It seems that, at least with TortoiseSVN, you set up the project repository on the server and then each developer has his/her own local copy of the project that is linked to this repository. This means that each person must have a copy of the project.
What we are looking for is a versioning system that does not force you to have a local copy. Rather, it would be nice that everyone simply accesses the shared server files and can edit them. Also, we would like a 'check-out' and 'check-in' feature where the file locks when checked out.
Anyone know of a good solution?
Thanks in advance, -Tim
This post has been edited by godspeedphi: 18 Aug, 2008 - 05:21 AM
I use TortiseSVN, it is true that each developer has a copy of the project (which can be a good thing, eg the server crashes) Also is does lock thes file on the server when a user checks a file out. Remember though to check files in at the end of the day, as only person who checked out can check it in.
I've used TortoiseSVN on a small project before, and did not witness it locking files.
As far as I understand, you set up a folder and check-out a sandbox (aka working copy) of the project. Let's say three people do this, then there are three people with checked-out copies. Let's say they all edit the same file at the same time and then commit. It doesn't lock the file, but will merge it instead. But merges are never really trustworthy. I've had it turn code into garbage text.
But, after looking around online, it seems that what my team is looking for really isn't around, nor is it recommended. So, I guess I will suggest that they use TortoiseSVN and deal with working copies.
Thanks, -Tim
Oh, and...
one thing I don't really care for, at least with TortoiseSVN, is that everyone must remember to update their folder frequently to avoid editing an old copy. I wish, somehow, each individual would see changes immediately without any need to request an update.
You make it sound like you just want everyone to work on a live copy [which is usually a bad idea]. Everyone having working copies and having to sync with a main server is a good thing.
Subversion does not automatically merge changes. If a file has changed since someone checked it out, they will get a "working copy out of date" error. Subversion lets them handle the merge.
I recommend committing lots of small changes instead of a couple large ones, and checking often for updates to your working copy. Depending on what client you use this may be done automatically.
There's a really good book on Subversion online here. I highly recommend you read it if you're planning to use Subversion.
If you REALLY don't like the idea of working copies, why not code up your own version control system without them [or get someone to do it for you]?
a word of advice, if you choose CVS or SVN. Split the work up so that only one person is working on any one file at a time. The reason for this is to avoid error-prone and time-intensive merges. I know that one of the benefits of SVN and CVS is that multiple people can work on the same file at the same time, but (and this is especially true in large projects) this introduces the possibility that someone will overwrite someone else's changes when merging. This doesn't happen often when you have a group of people that are experienced at merging. But it only takes one person having a bad day to mess something up. And, if you're particularly unlucky, the mistake will still compile and so might not be caught until much later, which is always a lot of fun.
Edit: If you've got the money, check out (no pun intended) ClearCase. Personally, I prefer free open source software, but from my experience using it, I know it has the features you mentioned.
This post has been edited by Programmist: 3 Sep, 2008 - 10:46 AM
I suggest reading up on HOW to use a version control system. One.. like Tom said, having everyone work on a single live copy is most usually a bad idea, for many reasons, which if we have to explain I'd recommend reading on WHAT a version control system is. If you for some reason neeed everyone working on a single copy, I'd STILL use subversion, and have the copy everyone uses be a checked out version, so they can commit their changes when they are done, and rollback when someone eventually screws up.
SVN does not 'lock' files. You checkout the file you want to work on, and when you are done and its tested, commit it. If the file was changed while you were working on it, you'll get an error. This is where a little thinking on the part of the developer needs to happen, as you should do an UPGRADE before committing. This will copy the latest version and add flags to your script showing you where the changes were made. You edit the merged copy to make sure everything is fine, tell SVN you resolved the conflict, and then commit the final merged script.
If you are interested in IBM Rational ClearCase as your version control solution, you may want to know about new add-ons which simplify and automate some of ClearCase processes.
I've been using SVN in our office and it's worked out very well. We have 40-50 different projects under it's control at this point and no problems to report. For our combination of developers (php, flash, .net), nothing could have been better.
| 