Re: cvs is up

[Bruce Montrose <montrose@itd.nrl.navy.mil>]

Thanks for the cvs info. I did manage to get your checkout to work finally.
My prior attempts where thwarted because I had it in my head that I had
to setup a tunnel manually to get it to work. So I expected it to not work
and didn't notice a stupid mistake when setting up the CVS_RSH variable.

I am sure I will manage to incorporate more generality as I rewrite httpap
to use what I have done so far. Ideally, the best you could hope for would
be a generic application proxy that only requires information about the 
application
protocol. I don't see how you can avoid having your application proxy 
understand
the application protocol.

At 04:24 PM 6/27/2002 -0400, Roger Dingledine wrote:
>On Thu, Jun 27, 2002 at 09:22:15AM -0400, Bruce Montrose wrote:
> > I have not touched op/. I have been working only on common/ so far.
> > However, I will be making changes to httpap/ and smtpap/ soon if all
> > goes well on my end.
>
>Sounds good.
>
> > What other proxies might we be interested in? Shall I look into making
> > other application proxies?
>
>I'm not sure what other proxies we want. Paul?
>
>Ideally, I'd like a generic proxy that can work for all/most protocols. In
>theory that should be possible, since when it comes down to it,
>each proxy really only says "that IP, that port". (Right? I may be
>missing something.) I wonder if we should investigate using ipchains
>to redirect traffic into the OP. That would make the whole notion of
>separate application proxies redundant (at least on Linux).
>
> > Please explain how I should submit changed files to you. What about
> > changes needed to Makefiles when new files are created? Should I check
> > out, alter, and commit changes to the Makefiles as well? I'm 
> CVS-challenged,
> > so I need recipes and a brief explanation please. I suppose I need to 
> create
> > an ssh tunnel so that I can communicate through our firewall to your CVS
> > server. What port do I need to map when I make the tunnel for CVS?
>
>The very short version, (assuming you want to do development on a remote
>machine that can ssh out) :
>
>1) cd somewhere on your local machine that is an empty dir
>2) set your $CVS_RSH environment variable to 'ssh'
>3) cvs -d :ext:montrose@seul.org:/home/or/cvsroot/ checkout .
>(don't forget the .)
>
>Then do edits, etc. If you add a new file, type 'cvs add file'. If
>you want to remove a file, rm it and then 'cvs remove file'.
>Do 'cvs diff' to see what changes you've made, before committing.
>(You can give diff its normal arguments, e.g. cvs diff -u if you prefer
>unified diff)
>
>When you're ready to commit your changes, do "cvs commit". It will ask
>you for a short description of the changes you've made. (If you don't
>like vi, you may want to change your $EDITOR variable.)
>
>http://www.seul.org/sys/doc/cvs/ should give you an overview in a bit
>more detail. 'man cvs' will give you more info about the options that
>various commands can take. Google for "cvs documentation" for more.
>
>Before you do new editing, always do a 'cvs update -d -P' to make sure
>to integrate the changes that other people have made. 'cvs annotate file'
>will tell you who's responsible for each line in the file.
>
>You will end up typing your moria password on each checkout or
>update or commit, unless you've set up rsa authentication for ssh
>(this is another topic, though it's pretty straightforward to do).
>
>
>Let me know if you've got questions.
>--Roger