vc-next-action not behaving

vc-next-action not behaving

[David Abrahams]

In recent CVS builds of emacs (on NT), when I do `C-x v v' on an
*unmodified* file under version control, and I get:

  File is edited but read-only; making it writable
  File is under version-control; use C-x v v to check in/out

The file was  *not* edited, but emacs seems confused about that.  I
know I went through this with emacs and vc years ago; I just changed
machines and it's happening again.  Kept my .emacs and my .cvsrc, so I
can't imagine what the problem is.

If I subsequently edit the file and then do `C-x v u' the file
reverts, but I am left with a writable file where I previously had a
read-only file.  I have CVSREAD=1 in my environment.

Can anyone suggest a fix for this problem?

Thanks,
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: vc-next-action not behaving

[Andre Spiegel]

On Wed, 2005-05-25 at 21:10 -0400, David Abrahams wrote:

> In recent CVS builds of emacs (on NT), when I do `C-x v v' on an
> *unmodified* file under version control, and I get:
> 
>   File is edited but read-only; making it writable
>   File is under version-control; use C-x v v to check in/out

When you visit the file initially, what version state does it show on
the mode line?  Does it show something like "CVS-1.1", or "CVS:1.1".
The latter would mean that Emacs already considers the file edited when
you first visit it.

Emacs considers the file edited if the time stamp in CVS/Entries and the
mtime of the working file do not agree.  You could check these time
stamps for an unmodified file, you could also try and step through
vc-cvs-parse-entry, to see if the time stamps are properly analyzed.

Maybe it's a timezone issue?

Re: vc-next-action not behaving

[David Abrahams]

Andre Spiegel <spiegel@gnu.org> writes:

> On Wed, 2005-05-25 at 21:10 -0400, David Abrahams wrote:
>
>> In recent CVS builds of emacs (on NT), when I do `C-x v v' on an
>> *unmodified* file under version control, and I get:
>> 
>>   File is edited but read-only; making it writable
>>   File is under version-control; use C-x v v to check in/out
>
> When you visit the file initially, what version state does it show on
> the mode line?  Does it show something like "CVS-1.1", or "CVS:1.1".

It's the latter.

> The latter would mean that Emacs already considers the file edited when
> you first visit it.
>
> Emacs considers the file edited if the time stamp in CVS/Entries and the
> mtime of the working file do not agree.  You could check these time
> stamps for an unmodified file, 

Emacs diredit:

  -r--r--r--   1 dave     root        25944 05-25 20:28 index.htm

DIR /TW:

                                      05/25/2005  08:28 PM            25,944 index.htm
CVS/Entries

                      /index.htm/1.216/Wed May 25 23:28:50 2005//

Hum.  Nobody seems to agree about the hour!  

I'm on EST, which is GMT-05:00.  Even if one of these is supposed to
be a GMT time it doesn't agree with either of the others.  I'm using
CVS from Cygwin, which I have installed with its bin directories in my
regular Windows PATH all the time.

> you could also try and step through vc-cvs-parse-entry, to see if
> the time stamps are properly analyzed.
>
> Maybe it's a timezone issue?

Apparently it is, but I haven't a clue how I'd correct it!  Any ideas?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: vc-next-action not behaving

[Andre Spiegel]

On Thu, 2005-05-26 at 08:28 -0400, David Abrahams wrote:

> I'm on EST, which is GMT-05:00.  Even if one of these is supposed to
> be a GMT time it doesn't agree with either of the others.  I'm using
> CVS from Cygwin, which I have installed with its bin directories in my
> regular Windows PATH all the time.

Judging from your mail headers, you are currently at GMT-04:00 due to
daylight savings.  The time in CVS/Entries is supposed to be UTC (=GMT).
You should make sure that for a freshly checked out file, this is indeed
the case.  If it isn't, it's a setup problem with CVS and/or Cygwin or
Windows.

It doesn't really matter what time you get in a directory listing -- the
operating system is supposed to show you local time, but Emacs mtime (in
file-attributes) must, once again, be UTC.

I'm not familiar with NT at all, and I don't know how timezones are
managed on that operating system usually.  On Unix, the system clock
runs in UTC, which is converted to local time only upon display.  I
suspect that somewhere in there, you have a daylight savings
misconfiguration -- maybe some part of your system thinks it is running
under DST, and another doesn't.

Hope this helps.

Re: vc-next-action not behaving

[David Abrahams]

Andre Spiegel <spiegel@gnu.org> writes:

> On Thu, 2005-05-26 at 08:28 -0400, David Abrahams wrote:
>
>> I'm on EST, which is GMT-05:00.  Even if one of these is supposed to
>> be a GMT time it doesn't agree with either of the others.  I'm using
>> CVS from Cygwin, which I have installed with its bin directories in my
>> regular Windows PATH all the time.
>
> Judging from your mail headers, you are currently at GMT-04:00 due to
> daylight savings.  

I never can keep track of which side of DST I'm on.
Confirming... yeah, you're right.  Still doesn't explain anything.

> The time in CVS/Entries is supposed to be UTC (=GMT).
> You should make sure that for a freshly checked out file, this is indeed
> the case.  

It isn't.  Entries contains 16:46 right now and it's 17:46 GMT.

> If it isn't, it's a setup problem with CVS and/or Cygwin or Windows.

Well, those are the same three culprits I was considering once someone
pointed me at CVS/Entries.
>
> It doesn't really matter what time you get in a directory listing --
> the operating system is supposed to show you local time, but Emacs
> mtime (in file-attributes) must, once again, be UTC.

Okay, emacs appears to have the right mtime, although I have to have a
strange reading of the file-attributes doc in order to see it that
way:

 4. Last access time, as a list of two integers.
  First integer has high-order 16 bits of time, second has low 16 bits.

It's (17046 2788)

If that's really meant to be a 32-bit number and 17046 means 17:46,
there are some big gaps in numerical time. ;-)

> I'm not familiar with NT at all, and I don't know how timezones are
> managed on that operating system usually.  

A dialog box ;-)

> On Unix, the system clock runs in UTC, which is converted to local
> time only upon display.  I suspect that somewhere in there, you have
> a daylight savings misconfiguration -- maybe some part of your
> system thinks it is running under DST, and another doesn't.

Surely.

> Hope this helps.

A little, but I'm afraid I'm still stuck (just a little further
forward than I was).

The latest information I can find about this is from 2003, and I've
been using Cygwin CVS through DST changes for years without incident.

Another prominently indexed thread from 2001 ends with:
http://groups-beta.google.com/group/gnu.cvs.help/msg/8fe939925748a068?hl=en
so I'm almost afraid to ask.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: vc-next-action not behaving

[Andreas Schwab]

David Abrahams <dave@boost-consulting.com> writes:

> Okay, emacs appears to have the right mtime, although I have to have a
> strange reading of the file-attributes doc in order to see it that
> way:
>
>  4. Last access time, as a list of two integers.
>   First integer has high-order 16 bits of time, second has low 16 bits.
>
> It's (17046 2788)
>
> If that's really meant to be a 32-bit number and 17046 means 17:46,
> there are some big gaps in numerical time. ;-)

No.  The number is (+ (* 17046 65536) 2788), which is 1117129444, except
that the number would not be representable as a Lisp_Integer on a 32-bit
host.

$ date -u -d @1117129444
Do Mai 26 17:44:04 UTC 2005

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vc-next-action not behaving

[David Abrahams]

Andreas Schwab <schwab@suse.de> writes:

> David Abrahams <dave@boost-consulting.com> writes:
>
>> Okay, emacs appears to have the right mtime, although I have to have a
>> strange reading of the file-attributes doc in order to see it that
>> way:
>>
>>  4. Last access time, as a list of two integers.
>>   First integer has high-order 16 bits of time, second has low 16 bits.
>>
>> It's (17046 2788)
>>
>> If that's really meant to be a 32-bit number and 17046 means 17:46,
>> there are some big gaps in numerical time. ;-)
>
> No.  The number is (+ (* 17046 65536) 2788), which is 1117129444, except
> that the number would not be representable as a Lisp_Integer on a 32-bit
> host.

So, it's just a lucky coincidence that I saw "17046" and 17:46 was the file's
modification time.  But then, why is it showing as 17:44 below?

> $ date -u -d @1117129444
> Do Mai 26 17:44:04 UTC 2005


-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: vc-next-action not behaving

[Andreas Schwab]

David Abrahams <dave@boost-consulting.com> writes:

> So, it's just a lucky coincidence that I saw "17046" and 17:46 was the file's
> modification time.  But then, why is it showing as 17:44 below?

I have no idea.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vc-next-action not behaving

[Stefan Monnier]

> Emacs diredit:
>   -r--r--r--   1 dave     root        25944 05-25 20:28 index.htm
> DIR /TW:
>                                       05/25/2005  08:28 PM            25,944 index.htm
> CVS/Entries
>                       /index.htm/1.216/Wed May 25 23:28:50 2005//

> Hum.  Nobody seems to agree about the hour!  

Looks like a plain daylight-savings-time problem.  Pretty standard
MS screwage.  I'm sure if you google for it, you'll find lots more info.
The fix is to upgrade to a Free operating system or to run `cvs update' and
hope that `cvs update' will reset the time stamps.  The problem will most
likely occur at every DST change.


        Stefan

Re: vc-next-action not behaving

[David Abrahams]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Emacs diredit:
>>   -r--r--r--   1 dave     root        25944 05-25 20:28 index.htm
>> DIR /TW:
>>                                       05/25/2005  08:28 PM            25,944 index.htm
>> CVS/Entries
>>                       /index.htm/1.216/Wed May 25 23:28:50 2005//
>
>> Hum.  Nobody seems to agree about the hour!  
>
> Looks like a plain daylight-savings-time problem.  Pretty standard
> MS screwage.  I'm sure if you google for it, you'll find lots more
> info.

Lots of info that leads nowhere.

> The fix is to upgrade to a Free operating system or to run `cvs update' and
> hope that `cvs update' will reset the time stamps.  

Didn't work; this is a new checkout, not one I carried over from
before the DST change.  I've been using Cygwin CVS successfully for
years.  Can't imagine why this started happening now.

> The problem will most likely occur at every DST change.

Haven't had problems at DST boundaries in the past.

Thanks anyway.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Re: vc-next-action not behaving

[David Abrahams]

David Abrahams <dave@boost-consulting.com> writes:

>> The problem will most likely occur at every DST change.
>
> Haven't had problems at DST boundaries in the past.
>
> Thanks anyway.

Problem solved.  This was due to the stupid Borland C++ Builder X
installer which installed its own broken cvs executable that doesn't
account for the NT daylight savings "feature."  I renamed it and
everything went back to normal.  Sorry for the noise.  The info I got
here regarding CVS/Entries was a big help in tracking it down, though.

Thanks again.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com