On 9/13/05, Kazmierczak, Kevin <[EMAIL PROTECTED]> wrote: > > For whoever is using some sort of source code control, I'm curious on > how you have successfully set it up in a multi user environment working > on a shared server. > > > > Here is my problem (currently using vss): You have 3 developers working > on a site and they all have the site's directory setup as their working > directory all mapped to the proper vss project. When one person checks > out a file, the file is changed from read only to writeable. The user > that checked it out edits it, but before they check it in, another > developer clicks on the file and they aren't prompted to check it out > because it is already writable and without thinking there may be a > problem, they make some changes and edit the file and save.
That's exactly what checking out a file is for -- to make a file editable. The file is checked out into a specific location and made writeable. Anyone with access to that file can change it. So right now, everything's fine. Now developer one checks in their file and loses all their changes or it > doesn't reload and then developer 2 loses their changes, either or > someone loses data. It seems as if the shared development is the big > problem in the scenario. Actually, shared development isn't your problem -- shared ACCESS to the *same file* is your problem. Version control software (ANY version control software) knows how to control access to a file and synchronize it with the repository. But source control software doesn't work magic. There's no inherent difference between two people editing the same physical file (in a shared directory) and one developer making changes, then Undoing them, and making more changes. In either case, file is checked out in a known condition, changes are made, and the changes are reconciled with the repository upon checkin. I've tried cvs and subversion as well and they > don't seem to like the shared environment either because all the meta > data is shared on the server and it gets confused with who the current > user is. I think the root problem is that you're trying to control source in a non-optimal way -- working directories are exactly that -- for working. Once a file is checked out in a working directory, source control doesn't care what happens until it's checked back in. That's by *design* :) How are people doing this? What am I missing? I've tried eclipse with > vss and homesite with vss and I am able to corrupt files with no problem > using the method described above. If by "corrupt" you mean overwrite changes, then yes, you should have no problem doing that with the scenario you outline. My only solution is to force > developers to check out their files with the VSS client which takes away > from having everything in one ide and still leaves the ability for > someone to mess it up. Actually, while that doesn't seem like an enormous hurdle (anyone using CVS or SVN, etc have to use the client/CLI to check things in/out in homesite since there's no source provider for those built-in), what your real solution entails is giving each developer an individual working directory with their own copy of the code. With virtual sites, it's only a few minutes of work and will definitely pay dividends. Of course then you have to have a deployment solution (so everyones changes go out onto the staging server), but there are many options for that such as Ant or even the deployment tools in HS -- John Paul Ashenfelter CTO/Transitionpoint (blog) http://www.ashenfelter.com (email) [EMAIL PROTECTED] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:218043 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
