Re: How to tell CVS that it should use the proper date/time
hi larry, oops, I couldn't find a -d option in cvs' info docus. Perhaps it's still not supported in 1.11.5?! It's mentioned in the Quick Reference, but not in the detailed guide. It's not new, it's been there forever. thanks for the hint. Strange that it isn't visible in the info manual! Look like that needs some refinement or update... Anyway, as I see now there doesn't seem to be a comparable option for the add command, though. Only import would allow this, add won't! Am I right? If so, it would be quite strange... Marko ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to tell CVS that it should use the proper date/time
marko wrote: Anyway, as I see now there doesn't seem to be a comparable option for the add command, though. Only import would allow this, add won't! Am I right? If so, it would be quite strange... The option is not there *because* it is not a good idea to do this. Marko, let me repeat what Frederic asked when you first started this thread: Why do you want to do this? Generally speaking, you should let CVS handle details like the timestamps. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
Hi Larry, On Thu, 8 Jul 2004, Larry Jones wrote: If you mean you want checkout to record the current timestamp of the file rather than the time of the checkin, that would also break things like make. Import, however, has the -d option to do just that. oops, I couldn't find a -d option in cvs' info docus. Perhaps it's still not supported in 1.11.5?! Marko ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
marko writes: oops, I couldn't find a -d option in cvs' info docus. Perhaps it's still not supported in 1.11.5?! It's mentioned in the Quick Reference, but not in the detailed guide. It's not new, it's been there forever. -Larry Jones I like maxims that don't encourage behavior modification. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
At 12:56 PM 7/8/2004, marko wrote: I wonder how CVS can be convinced to set the original date/time of a file at checkin time when I do a checkout! Use the Source! But, really. Do you want to do that? Do you expect to use make? Fred ___ Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/ ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
marko writes: I wonder how CVS can be convinced to set the original date/time of a file at checkin time when I do a checkout! I'm having a hard time parsing that sentence, but I think that's what it already does -- when you do a fresh checkout, the files have the timestamps of when they were checked in. That's not true for update, however, since it would break things like make. If you mean you want checkout to record the current timestamp of the file rather than the time of the checkin, that would also break things like make. Import, however, has the -d option to do just that. -Larry Jones Somebody's always running my life. I never get to do what I want to do. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to tell CVS that it should use the proper date/time
[EMAIL PROTECTED] wrote: If you mean you want checkout to record the current timestamp of the file rather than the time of the checkin, that would also break things like make. I'm not sure I follow this. How would using the timestamp of the file instead of the time of checkin break make? Presumably, the file's timestamp would be older than the time of the checkin, and on a fresh checkout there won't be any targets (e.g. *.o) at all. Hmmm... well, I guess I'm assuming that the targets will be created in the same directory as, or a subdirectory of, the source directory. Is that a poor assumption? Might the targets be in a directory completely outside of CVS's knowledge? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to tell CVS that it should use the proper date/time
--- Forwarded mail from [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: If you mean you want checkout to record the current timestamp of the file rather than the time of the checkin, that would also break things like make. I'm not sure I follow this. How would using the timestamp of the file instead of the time of checkin break make? Presumably, the file's timestamp would be older than the time of the checkin, and on a fresh checkout there won't be any targets (e.g. *.o) at all. Hmmm... well, I guess I'm assuming that the targets will be created in the same directory as, or a subdirectory of, the source directory. Is that a poor assumption? Might the targets be in a directory completely outside of CVS's knowledge? The problem is that the CVS doesn't guarantee that the files are copied into the workspace in the same order in which they were checked in. So for derived files like y.tab.c and y.tab.h that might be checked in (these might be bad examples, but you know what I mean), unpleasant things can happen if their timestamps come out in the wrong order. --- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: How to tell CVS that it should use the proper date/time
[EMAIL PROTECTED] wrote: I'm not sure I follow this. How would using the timestamp of the file instead of the time of checkin break make? The problem is that the CVS doesn't guarantee that the files are copied into the workspace in the same order in which they were checked in. So for derived files like y.tab.c and y.tab.h that might be checked in (these might be bad examples, but you know what I mean), unpleasant things can happen if their timestamps come out in the wrong order. I think I was unclear - I meant the timestamp that the file had before it was checked in, not the timestamp of the file when it was checked out. I *think* that's what the OP was looking for. In other words, if I last modified the file on June 30, and checked it in on July 1, currently when you check out the file, CVS will set its timestamp to the check-in time of July 1. If, instead, CVS set its time to the last modified time of June 30, how would that break make? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
Jim.Hyslop wrote: [EMAIL PROTECTED] wrote: I'm not sure I follow this. How would using the timestamp of the file instead of the time of checkin break make? The problem is that the CVS doesn't guarantee that the files are copied into the workspace in the same order in which they were checked in. So for derived files like y.tab.c and y.tab.h that might be checked in (these might be bad examples, but you know what I mean), unpleasant things can happen if their timestamps come out in the wrong order. I think I was unclear - I meant the timestamp that the file had before it was checked in, not the timestamp of the file when it was checked out. I *think* that's what the OP was looking for. In other words, if I last modified the file on June 30, and checked it in on July 1, currently when you check out the file, CVS will set its timestamp to the check-in time of July 1. If, instead, CVS set its time to the last modified time of June 30, how would that break make? It wouldn't, but it could break the RCS archive file contract that says that internal commit timestamps will be increasing. This would in turn break operation of the -D arguments to various commands. It could also open up a minor security hole in that the server would now have to trust the client for timestamps. It's possible that you could achieve the result you are describing by adding a newphrase to the RCS files so that timestamps and commit times were stored separately for each revision. I don't think you could cause any major havoc if those time stamps were then used instead of commit times to set timestamps just on checkout (not update). Derek -- Get CVS support at http://ximbiot.com! ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
Derek R. Price writes: It wouldn't, but it could break the RCS archive file contract that says that internal commit timestamps will be increasing. Is there such a contract, given that RCS's ci has a -d option that lets you set the date to anything you want (and its default is the file's timestamp, not the current time)? On further consideration, I'm not sure that that would cause any problems (unless CVS really does depend on revisions being in date order). -Larry Jones This game lends itself to certain abuses. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
Larry Jones wrote:
Derek R. Price writes:
It wouldn't, but it could break the RCS archive file contract that says
that internal commit timestamps will be increasing.
Is there such a contract, given that RCS's ci has a -d option that lets
you set the date to anything you want (and its default is the file's
timestamp, not the current time)? On further consideration, I'm not
sure that that would cause any problems (unless CVS really does depend
on revisions being in date order).
Yes. RCS_getdatebranch() in rcs.c stops when it finds the first date
that is too old. From RCS_getdatebranch() in rcs.c:
/* walk the next pointers until you find the end, or the date is too
late */
while (p != NULL)
{
vers = p-data;
if (RCS_datecmp (vers-date, date) = 0) cur_rev = vers-version;
else break;
/* if there is a next version, find the node */
if (vers-next != NULL) p = findnode (rcs-versions, vers-next);
else p = NULL;
}
Derek
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/info-cvs
Re: How to tell CVS that it should use the proper date/time
Derek R. Price wrote: Yes. RCS_getdatebranch() in rcs.c stops when it finds the first date that is too old. From RCS_getdatebranch() in rcs.c: Of course, this doesn't necessarily mean that that can't be fixed, but any archive file that took advantage of it would no longer work quite correctly with old versions of CVS and maybe RCS. I also suspect that there will be at least some administrators that would rather we set at least the commit timestamps securely in client/server mode. Derek ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
