bug-cvs
[Top][All Lists]
Advanced

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

Re: Feature request/ideas


From: Derek Price
Subject: Re: Feature request/ideas
Date: Thu, 03 Mar 2005 09:09:57 -0500
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frank Hemer wrote:

|> | A rational way. As a second step I would suggest to change the
|> | extensions (.prev, .next, .xxx) to be allowed in head position
|> too, | but I'm note sure where the sandbox tag gets processed. If
|>  | translate_tags() could take that into account, its not a big
|> deal | ... Where is this state cached?
|>
|> It's cached in the CVS/Entries files in each subdir.  CVS looks
|> it up in the Version_TS in vers_ts.c and decides to set it in the
|> Vers_TS structure it returns only if the TAG passed to the
|> function (via -r or something, somewhere) is not set.  I think it
|> could be caught there - if the TAG is .XXX  (and not .trunk),
|> then set the vers_ts->tag to STICKY.XXX.
|
|
| Ok, thats the 'client' side. But where is it cached on the 'server'
| side?


The server side looks in the same place, basically.  The first thing a
client does after authentication is to send information on all the
files being operated on to the server.  The first thing the server
does is use that information to recreate a copy of the client's
workspace in tmp space on the server.  It then launches a second
server which mostly operates from that workspace like it is running on
the client.  For most intents and purposes this second server's
behavior is indistinguishable from the client's.  The first server
then wraps up the data from the second server's operation and sends it
back to the client.

|> | So probably the expression used should connote this. After some
|>  | consideration, I would vote for '.origin' here. I disagree
|> with | being meaningless. I often export a project state into a
|> local | repository, work on it, and when I'm done, move the files
|> back to | the remote repository's sandbox. During local
|> development I often | want to compare to the initial version of a
|> file, and using a | single tag for this is just easy. Granted
|> there are other ways to | achieve this, but they're not as easy
|> to handle.
|>
|> That's fine for 1.1, but how does this help you for a branch?
|> You might want to diff against the root, but it doesn't make much
|> sense to care about the first revision on the branch.
|
|
| Good point. What about resolving '.origin' to the very first
| revision of the mainline?


I don't have any reason to object to that.

Regards,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCJxq0LD1OTBfyMaQRAoY7AJ91OLGBtDThQlqlFeTcvC1dSyYHrQCfZO9Y
Fpx1Q5wvrCdfbsU/3kuVLjY=
=7sjF
-----END PGP SIGNATURE-----






reply via email to

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