[Top][All Lists]

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

Re: `cvs add -m' in server mode

From: Derek Robert Price
Subject: Re: `cvs add -m' in server mode
Date: Tue, 29 Apr 2003 15:40:40 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Mark D. Baushke wrote:

Derek Robert Price <derek@ximbiot.com> writes:
Mark D. Baushke wrote:
Derek Robert Price <derek@ximbiot.com> writes:

I have no strong feelings about it. However, given both the client
and the server will need to agree on the meaning of the text for it
to actually use the data, I would have thought introduction of
another client/server primitive for setting the description of a
controlled file might be the right way to do it.
Actually, this is exactly why I decided to do it this way.  I don't
need a new primitive since the client sends the Entry to the server
without interpreting it.  When the client does need to interpret it,
it will (hopefully) ignore anything after the `+' since it parses it
as the ts_conflict field and then will ignore it since it has a rev
`0' which it knows is a new file.

Hmmm..., I am confused.

If I'm correct, in other words, fixing this this way will allow the
client/server problem to be fixed on the server side without upgrading

How does the text get into the CVS/Entries file on the client side to
send thru to the server? I am under the impression that existing
clients would take a command like:

        cvs add -m'description field goes here' foo

and ignore the -m option to add and write a CVS/Entries file with

/foo/0/dummy timestamp//

No, the server sends the Entries line to the client, and the client writes it without interpretation, I think. Since the client sends the server the -m and its argument, the server can choose to write the entry.

No CVS/foo,t file appears to be created with the descriptive text unless
you are using a local cvs repository.

Well, it is created, in the temporary copy of the user's workspace on the server but the server never asks the client to create the file since it doesn't know a way to ask. Of course, the ,t file is then wiped out when add finishes running and is generally long gone by the time anyone gets around to running commit on the added file. Since the ,t file wasn't created on the client, the client no longer knows to tell the server about the description text.

After you finish coding up your change, the CVS/Entries file would have

/foo/0/dummy timestamp +description field goes here//

so, if the server was not updated it would ignore the new ts_conflict
text and if the server had been updated it would add the description

Exactly.  I thought you said you didn't understand?

Instead of this approach, another approach would be for the client cvs
add to create the CVS/foo,t file with the description as a
non-client/server cvs add command would have done and then it could use
the same protocol that 'cvs admin -t' uses to set the description after
the file is added. In this way only the client really needs to be updated
to get the impact of the description field in client/server mode.

Yeah, but this would require a client fix. I like server fixes when they can be made.

Also, the fix to add will work even if the user isn't in the cvsadmin group.

I do not see how your new proposal will not require both client and
server to be upgraded to get descriptive text into client/server
operation, so I must have misunderstood your proposal.

Hopefully it is clearer now.

If I understand what you are suggesting, `cvs admin' already does this
when passed the `-t' option, in local or client/server mode.

My text was not clear... my apologies. Let me try again...

I meant that it might be possible to use the same protocol
 "Argument -t-" <descriptive text>"\012Argumentx \012"

for both the addition of a cvs add description and cvs admin command.

I fear the above may also be confusing... my apologies if this is the

Think I got it, but I think I already answered it now.




Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
I will not belch the National Anthem.
I will not belch the National Anthem.
I will not belch the National Anthem...

         - Bart Simpson on chalkboard, _The Simpsons_

reply via email to

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