Dennis von Ferenczy <[EMAIL PROTECTED]> wrote: > Thanks for your advice. But what will be the advantage? If I get you right, > then I would have to do a commit every time I want to test the changes in my > scripts,
Yes. > even if I have changed only a single line of code Yes. > - and even if the code is buggy. Yes. If you commit a bug, fix it and commit again. Try not to commit buggy code, but if it happens once in a while it's not that big a deal. You will want to tag the project when you believe there are no bugs, so you have a well-defined baseline to begin serious testing. You can also create a stabilization branch where you will do the bug fixes, or you can wait till you are ready to move the code to the production server. You *must* tag the state that you move to production and you *must* fix any post-release bugs on a branch, to isolate production from continuing work on the trunk. Having a trunk and one active branch will complicate the commitinfo script but it's doable. Can you run two instances of the testing server ? Then your loginfo hook can maintain two sandboxes, one on the trunk and one on the active release branch. You can use a floating tag name for the active branch to avoid rewriting the loginfo script all the time. There are ways; it's just normal hacking. > Right now I work locally, have the files mirrored using SSH > (I'm not sure if cvs can use SSH) can immediately try my changes and if > everything works as desired I do a commit. So you upload instead of cvs-commit, and something goes wrong right at that step and the remote sandbox loses its CVS subdirectories. Which is worse ? > Like this I can always be sure, > that code in the repository is actually code that is working correctly. No, the code can still be buggy, just not obviously so. You will commit buggy code every once in a while even if you can test before committing. Like I said, it's not that big a deal. The best solution would be to fix your IDE's habit of clobbering the remote CVS directories. Failing that, my proposal is quite workable once you get used to it. -- pa at panix dot com _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
