Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
On Wed, 25 Jan 2006 10:28:22 -0800, Sanjay.Uttam at VerizonWireless.com wrote: >All, >I appreciate all help and suggestions...However, the question and decision >to prohibit IIS from running on developer machines is _well_ out of my >reach. I'm sure I could circumvent whatever steps have been put in place to >prevent me from utilizing IIS locally - however that simply is not a viable >option for me. Maybe you should work for a company thta understands the needs of their software developers. It seems especially stupid to have you develop web applications while denying you the use of a web server while developing your code! If all you can do is upload your code to the single webserver in existence then what about all other developers? Are you to apply for a time slot in which to test your contributions? This really sounds like a corporate horrorstory.... >In any case, I'd like to make sure I have a clear understanding of the >suggestions that have been made thus far, barring the switch to some other >web server/framework/etc. > >- Create a sandbox/module on the network on the machine running CVSNT server >- Install a plug-in or run a script that updates the web server directory >(diff physical box) when a commit is made to the sandbox/module on the CVSNT >server No, that is not the suggested way. Instead: 1) You keep your develpment sources checked out *on your own hard disk* where you edit the files. 2) When it is time for testing you commit your changes to the server, a normal and simple operation. 3) On the CVSNT server you have prepared a sandbox with the web files by checking them out once. This sandbox will contain the latest version of all files. 4) When your commit reaches the CVSNT server it finishes off by running the CVSROOT/postcommit script file. Here you have entered a call to a batch file like this (example from my server): postcommit contents: mywebsite D:/Websites/mywebsite/updatewebsite.bat contents of the updatewebsite.bat file: @echo off d: cd d:\Websites\mywebsite cvs update -d echo Website update ready! Note that the newer CVSNT servers have a better way of keeping a website up to date, so if you have a server thta is recent enough you can instead use the CVSROOT/shadow file to specify the website to keep up-to-date. Then it is done without using the postcommit script. > >Please forgive my ignorance here, I've got no real experience administering >source control environments until now. > >Lastly - As of now, if I create a module on the CVSNT server from TCVS on >my local machine...if someone else goes to check it out, there are prompted >for my password (we are utilizing SSPI) No, they are never prompted for a password if you use SSPI! This protocl uses the Windows login as the user to authenticate. >Is there a way to grant multiple >users access to a module/repository/etc [while still utilizing SSPI]? It is handled automatically through Windows permissions on the repository files via NTFS. But you can also use the cvs chacl command to create a more fine-grained permission structure in your repository. > Do we >need to create the module with some generic account/group so that we all >have access? If so - wouldn't we lose the accountability (ie, who committed >what version) All commits are logged by user, you can always see exactly who did what in a repository file! That is what SourceControl is all about, really (keeping all revisions and saving commit data with each revision). /Bo (Bo Berglund, developer in Sweden)