info-cvs
[Top][All Lists]
Advanced

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

Re: CVS diff and unknown files.


From: Sergei Organov
Subject: Re: CVS diff and unknown files.
Date: 01 Feb 2005 13:51:06 +0300
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp)

Paul Sander <address@hidden> writes:
> On Jan 30, 2005, at 2:18 AM, address@hidden wrote:
> 
> > Todd Denniston <address@hidden> writes:
> >> Sergei Organov wrote:
> >>>
> >>> Todd Denniston <address@hidden> writes:
> >>>>
> >>>> If "cvs -n commit" runs the triggers to do your check(see my
> >>>> question above), I have another question: in a remote server setup
> >>>> (i.e., :pserver:, :ext:) which test was failed, the add or the
> >>>> normal commit?
> >>>
> >>> With my approach there is no add-to-working-copy-time triggers,
> >>> adding of a new file is normal commit (the commit time trigger
> >>> should have a way to check if the file is already in the repository
> >>> or not). So your question reduces to the following: "how client
> >>> knows what exactly failed?" and the answer is "through appropriate
> >>> error message, as usual".
> >>>
> >>> Please notice that with separate add-to-working-copy-time triggers the
> >>> situation at commit time is exactly the same as those triggers must be
> >>> run at commit time anyway. What's an answer to your question in this
> >>> case?
> >>
> >> There is a certain amount beauty in the simplicity in keeping the status
> >> quo, which works. :)
> >
> > Unfortunately, it doesn't work, sorry -- that's why I've initiated this
> > thread in the first place.
> 
> Huh? You know what "status quo" means, right? It means "the way things
> are".

Sure. And "the way things are" aka "status quo" doesn't work for me, --
that's the problem.

> You seem to be arguing both ways.

I don't think so. I even can't guess what are these ways you have in your
mind.

> Would you post a message stating your point of view, completely,
> please? Thanks!

I need a way to generate 'cvs diff' against read-only repository. To
achieve this it's enough to fix 'cvs add' so that it either doesn't
contact the repository at all, or just doesn't require write permission
to the repository to succeed.

As a response to the question, I've got a reference to the discussion
about new 'cvs add' implementation, where you, Paul, argue in favor of
new implementation of 'cvs add' to contact the repository to run some
new scripts you called add-time triggers. I then tried to tell that I'm
yet another person here who is against such a thing and tried to suggest
another way of achieving your actual goal, -- checking something against
repository at add-to-working-copy time using existing commit-time
triggers.

-- 
Sergei.





reply via email to

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