[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Obtaining the files modified/created after a failed/successful build

From: Spiro Trikaliotis
Subject: Re: Obtaining the files modified/created after a failed/successful build of CVS repository
Date: Wed, 24 Sep 2008 20:11:00 +0200
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

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 <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
> CVS.)

Although I did not want to comment on this in the first place, I must
admit that I wholeheartedly agree here.


Spiro R. Trikaliotis                               

reply via email to

[Prev in Thread] Current Thread [Next in Thread]