Re: Setting up first repository
on 5/3/05 19:23, Pierre Asselin at [EMAIL PROTECTED] wrote: Roddie [EMAIL PROTECTED] wrote: [ ... ] The repository could be on either computer, but I plan to put it on the co-lo. You may want to dry-run this on your laptop. Run cvs init to start a repository, use it locally for a while, wipe it out when you have enough experience to init a new repository on your co-lo. The dry run is just to play with cvs commands for a while. You have a pretty strong incentive to switch to your final repository so you can distribute files to the live site through cvs. This is a good idea and I've been trying it. I can log in OK, but when I try to import a trial project using cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/CVS import myProj no-vendor release-0 I get cvs [import aborted]: reading CVS/Tag: Not a directory. I may also have Unix permission problems - I had to make CVSROOT chmod 757 (though there may be lesser options - Unix permissions are not instinctive yet!) I have a passwd file with roddie:abcxyz:roddie where roddie is a Unix administrator. [ ... ] [...] Occasionally I make changes direct to the live site. These are usually trivial updates of content, but remembering to make them also in the development files is a nuisance. In this instance I would make changes to the live site, commit them, and then update the development sandbox. Then your live site should be a sandbox, and it should be on a branch. Otherwise, you won't be allowed to commit your trivial tweaks without first running an update, and that would force you to deploy changes sooner than you would like. Good point - I hadn't foreseen the need for a branch so early in the learning curve. Having a release branch is pretty standard. You fix bugs on the branch and merge them back to the trunk so you don't have to fix them twice. When your trunk is good, you cut a new release branch and update the live sandbox to the new branch. Post again if the process is not clear to you. Thanks to everyone who responded. I really appreciate the help. Roddie Grant ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Roddie [EMAIL PROTECTED] wrote: [a test repository] is a good idea and I've been trying it. I can log in OK, but when I try to import a trial project using cvs -d :pserver:[EMAIL PROTECTED]:/usr/local/CVS import myProj no-vendor release-0 I get cvs [import aborted]: reading CVS/Tag: Not a directory. pserver ? Why not just :local:/usr/local/CVS ? No xinetd, no login, no passwords to set up... When you put a cvs server on your colocation box I recommend :ext: with CVS_RSH=ssh and public key authentication. I assume you already have the ssh part set up ? Othwerwise how do you reach your colocated machine ? I may also have Unix permission problems - I had to make CVSROOT chmod 757 (though there may be lesser options - Unix permissions are not instinctive yet!) The usual directory permissions are 770 + setgid to a group to which all the developers belong. The setgid bit (on Linux) is to make sure any subdirectories inherit the group of their parents. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Roddie [EMAIL PROTECTED] wrote: I'm new to CVS, and I've been reading up about it for some weeks. [ ... ] I'm a one-man website developer. As things have turned out, I do relatively complex on-going work on a small number of sites. Development is on my OS X Mac laptop, and deployment is on my own RH Linux co-lo. The repository could be on either computer, but I plan to put it on the co-lo. You may want to dry-run this on your laptop. Run cvs init to start a repository, use it locally for a while, wipe it out when you have enough experience to init a new repository on your co-lo. The dry run is just to play with cvs commands for a while. You have a pretty strong incentive to switch to your final repository so you can distribute files to the live site through cvs. [ ... ] The shared directory holds libraries and other files needed by all the other sites. Each site uses symlinks so that the shared files appear to be in the correct place for that site. Sometimes it helps to think of your sandbox as the *source tree* of your web site rather than the web site itself. Planting the symbolic links is now a trivial compilation step that you perform after checkout or update. This should be scripted, and the script should be part of your sandbox, under revision control like the rest. I plan to have the sites directory as the project. There would be three sandboxes to start with: a development sandbox on the Mac laptop; a test sandbox on the co-lo (to iron out any MacLinux issues); and the live sites in a sandbox on the co-lo. Sounds good. Normally, development will take place on the Mac, be committed, the test sandbox updated, tested and committed, and then the live site sandbox (and the Mac if necessary) updated. Or you could have a scripted installation step to copy the test sandbox to the live site, which may or may not be a CVS sandbox. Occasionally I make changes direct to the live site. These are usually trivial updates of content, but remembering to make them also in the development files is a nuisance. In this instance I would make changes to the live site, commit them, and then update the development sandbox. Then your live site should be a sandbox, and it should be on a branch. Otherwise, you won't be allowed to commit your trivial tweaks without first running an update, and that would force you to deploy changes sooner than you would like. Having a release branch is pretty standard. You fix bugs on the branch and merge them back to the trunk so you don't have to fix them twice. When your trunk is good, you cut a new release branch and update the live sandbox to the new branch. Post again if the process is not clear to you. -- pa at panix dot com ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Setting up first repository
Roddie wrote: A lot of stuff that sounds pretty good. Plus: The shared directory holds libraries and other files needed by all the other sites. Each site uses symlinks so that the shared files appear to be in the correct place for that site. As I understand it, the symlinks should not be part of the repository, but created manually. Not sure where you heard that, but it will cause you much more work. I use symlinks in the repository, with no problems. You might consider using ampersand modules instead - that's what they're designed for. Have a closer look at the documentation of the modules file (in the administrative files section of the manual, IIRC). Is all this correct, complete and sensible? I'm open to any advice. Other than the symlink comments above, sounds good to me. Make sure your web server knows to ignore directories named 'CVS' (I believe Apache has an option to allow you to do that). -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Setting up first repository
[EMAIL PROTECTED] wrote: Jim.Hyslop writes: Not sure where you heard that, but it will cause you much more work. I use symlinks in the repository, with no problems. What kind of symlinks? Although it's not recommended, you can symlink *directories* in the repository, as long as you don't use LOCKDIR in your config file to put the lock files somewhere else. Right, I forgot to qualify that part - yes, our symlinks are for directories, and we do not use LOCKDIR. Oh, and doesn't CVS have problems if $CVSROOT/CVSROOT is symlinked? Or has that been fixed? Or am I mis-remembering something? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Jim.Hyslop writes: Not sure where you heard that, but it will cause you much more work. I use symlinks in the repository, with no problems. What kind of symlinks? Although it's not recommended, you can symlink *directories* in the repository, as long as you don't use LOCKDIR in your config file to put the lock files somewhere else. If you do, or if you symlink individual files, you're completely defeating CVS's locking scheme and opening yourself up to all sorts of potential corruption. -Larry Jones OK, there IS a middle ground, but it's for sissy weasels. -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Setting up first repository
Jim.Hyslop writes: Oh, and doesn't CVS have problems if $CVSROOT/CVSROOT is symlinked? Or has that been fixed? I believe that's been fixed. -Larry Jones Good gravy, whose side are you on?! -- Calvin ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
