Hello Mark, I am sorry for the late answer, I was busy.
* On Fri, Sep 12, 2008 at 09:00:43PM -0700 Mark D. Baushke wrote: > Spiro Trikaliotis <[EMAIL PROTECTED]> writes: > > > For example, in my case, I use Windows as an additional server. That is, > > my main server is on a unixoid machine. However, when I am on travel > > with my laptop (without network access), I take an rsync'ed copy of the > > repository with me. This way, I can work offline (read-only!) with CVS > > as if I would have network access. Of course, I could use the :local: > > access method for this. However, I like to use CVS the same way as I use > > it with the real server, this, I am always using the :ext: access > > method. Additionally, if I go to another machine (and my laptop is > > around), I use that repository, too. So, in this case, I have to use > > :ext:. > > Using :fork: is probably a better solution to your particular need. It > acts as client/server without needed to use rsh or ssh transport as > :ext: needs. Well, for me, I still think :ext: is better for my purpose. If I would use :fork:, I would have to use a tool like cvschroot(1) to change between my :fork: and my :ext: CVS roots, or I would have to use the option "-d :fork:/mypath" for every CVS command. This would be annoying. On my machine, there is always an ssh daemon running (for other reasons). Additionally, instead of using my "real" server name, I use some "role" names for the server name (for example, the MYCVS in :ext:[EMAIL PROTECTED]:/path). My .ssh/config is automatically adjusted (by some other means) to make sure the role name MYCVS is always pointing to the "right" machine. As I make sure that the paths are compatible between the machines, this comes as a very handy tool. For me, this is much more handy than switching to the :fork: option. > > ... - but, as we all know, some developers do not consider :pserver: > > to be a good idea at the first place, so, this might not be such a big > > restriction. > > Yup. I still advocate that :pserver: should be removed or at least never > compiled by default... (The authentication business should be left to > the operating system and NOT poorly managed by a user-level program like > CVS.) Although I did not want to comment on this in the first place, I must admit that I wholeheartedly agree here. Regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/
