[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Obtaining the files modified/created after a failed/successful build
Re: Obtaining the files modified/created after a failed/successful build of CVS repository
Wed, 24 Sep 2008 20:11:00 +0200
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 <address@hidden> 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
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:address@hidden:/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
Although I did not want to comment on this in the first place, I must
admit that I wholeheartedly agree here.
Spiro R. Trikaliotis http://opencbm.sf.net/