Re: CVS-Directories disappear when uploading per SFTP-Client

[Todd Denniston]

Dennis von Ferenczy wrote:
> 
> >
> > Dennis von Ferenczy <address@hidden> wrote:
> >
<SNIP>
> > Yes.  Get a CVS client for your local machine and do your cvs
> > commits from there behind the IDE's back.  On the CVS server
> > == web server, use the loginfo hook to keep a reference
> > sandbox up to date, from which the web site operates.
> > https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC158
> >
> 
> 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, even if I have changed only a single line of code - and even if the
> code is buggy. 

OK, your above comment and your following comment seem to contradict each
other.
If you are testing locally (on your development box, using your sand box)
why would you need to commit to the Production CVS/WEB server with a posibly
broken change set? If you can currently test on your local box, then make
your checkout to that location, do your mods and tests, then when you are
done, and have a good change set, do a commit.
What you have been doing with SFTP is half of what CVS will do for you, IF
YOU LET IT.

> 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. Like this I can always be sure,
> that code in the repository is actually code that is working correctly.

If you re-read my message you should see that CVS can use ssh, but you have
to tell CVS to use ssh instead of rsh by setting `export CVS_RSH=ssh` (in a
unix environment, there is a way to do it with cvsnt as well, but you will
need to read their wiki[1]). 
BTW I suggest you run `cvs version` in your windows environment and include
its output with your next email, it might help us answer some of the
questions you have.


If I understand your workflow it goes something like this:
1) cvs checkout on server machine.
2) sftp checkout to dev machine.
3) make mods and test on dev machine.
4) sftp checkout back to server machine.
5) cvs commit changes on server machine.
6) sftp changes from dev machine to the production web server.

If you setup cvs, using ssh, you should be able to change your workflow to:
1} cvs checkout on dev machine.
2} make mods and test on dev machine.
3} cvs commit changes on dev machine.
4} login to the production area, issue `cvs update`.

if steps 3) and 2} involve ftping files to the production webserver, I
suggest you spend time rereading Jim Hyslop's email. Best practices usually
involve having a test 'server'/setup where you test all your work and when
it is working then you commit & tag, and then login to the production area
and do a `cvs update` from a known working tag. 

[1] http://www.cvsnt.org/wiki

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter