UPDATE Does Not Return the Most Recent Revision

Short Problem Description:
A CVS Update command is no longer returning the most recent
revision of
files in the CVS repository.

History and Specs:
I have been using CVSNT every day for a couple of years now
without any
problems; version 2.0.58d.  I use TortoiseCVS as my client;
version 1.8.9.
CVSNT is running on a Win2003 server.  Tortoise clients run
on WinXP Pro
development machines.

Detail Scenario:
Last Friday, a CVS update stopped returning the most recent
revision of
files in the HEAD branch.  Since then, I have tested this
multiple times
with the same result.  For example, I made a change to an
existing file.
Before changes, that file revision number was 1.1.  I did a
commit which
incremented the revision number to 1.2.  A CVS log command
shows both
revisions in the repository and shows that 1.2 is the most
recent HEAD
revision number.  I followed that up with a CVS update
command and the file
"rolls back" to revision 1.1 and my changes are no
longer in my sandbox.  If
I make my changes again, and commit again, the revision
number rolls to
something like 1.1.2.1.  Further CVS update commands
continue to bring me
back to revision 1.1.  

Thinking this might be a problem with Tortoise, I stopped
using the visual
portion of the client and started typing in the CVS command
by hand in a DOS
box.  The results were the same.  Here is the syntax of my
commands:
"C:Program FilesTortoiseCVScvs.exe" update -d
-P .  (Run from a source
file folder to update the whole folder.)
"C:Program FilesTortoiseCVScvs.exe" log
./TortoiseNotes.txt  (Run on a
specific file to get historical information.)

Thinking this had something to do with sticky-ness, tried
getting a specific
revision.  This brought the correct revision number into my
sandbox, but
then left a sticky tag (either date or number; I tried both)
on the file.
No further changes could be committed.  I then cleared the
sticky tag using
CVS update -A and was again "rolled back" to a
revision that was not the
latest revision. (i.e. revision 1.1 in my previous
example.)

I'm not sure what to do at this point as I can't get CVS to
give me the
latest revision of a file using a normal update.  This is
happening for
every developer on our team and is causing significant
problem when our
source tree is updated and local changes are being put in .#
files when
"roll backs" happen.  Can anyone could shed some
light on this problem?

Thank you.
 
Brandon Frost

_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

Update:
In desperation, I went to the server that runs CVSNT and
stopped and
restarted both CVSNT services.  This seems to have resolved
the issue.  I
can now do a regular CVS update and get the latest file
revisions.  CVSNT is
no longer stuck on an old revision number.

Since I have a quick and easy solution, this issue is no
longer a huge
problem.  However, CVSNT did somehow get in this state.  I
don't want this
issue to recur.  Is this a known bug that may happen again? 
Will an upgrade
to CVSNT version 2.5 fix this issue?

Thank you.

Brandon Frost

-----Original Message-----
From: cvsnt-bouncescvsnt.org [mailto:cvsnt-bouncescvsnt.org] On Behalf Of
Brandon Frost
Sent: Tuesday, March 20, 2007 9:41 AM
To: cvsntcvsnt.org
Subject: [cvsnt] UPDATE Does Not Return the Most Recent
Revision

Short Problem Description:
A CVS Update command is no longer returning the most recent
revision of
files in the CVS repository.

History and Specs:
I have been using CVSNT every day for a couple of years now
without any
problems; version 2.0.58d.  I use TortoiseCVS as my client;
version 1.8.9.
CVSNT is running on a Win2003 server.  Tortoise clients run
on WinXP Pro
development machines.

Detail Scenario:
Last Friday, a CVS update stopped returning the most recent
revision of
files in the HEAD branch.  Since then, I have tested this
multiple times
with the same result.  For example, I made a change to an
existing file.
Before changes, that file revision number was 1.1.  I did a
commit which
incremented the revision number to 1.2.  A CVS log command
shows both
revisions in the repository and shows that 1.2 is the most
recent HEAD
revision number.  I followed that up with a CVS update
command and the file
"rolls back" to revision 1.1 and my changes are no
longer in my sandbox.  If
I make my changes again, and commit again, the revision
number rolls to
something like 1.1.2.1.  Further CVS update commands
continue to bring me
back to revision 1.1.  

Thinking this might be a problem with Tortoise, I stopped
using the visual
portion of the client and started typing in the CVS command
by hand in a DOS
box.  The results were the same.  Here is the syntax of my
commands:
"C:Program FilesTortoiseCVScvs.exe" update -d
-P .  (Run from a source
file folder to update the whole folder.) "C:Program
FilesTortoiseCVScvs.exe" log ./TortoiseNotes.txt 
(Run on a specific file
to get historical information.)

Thinking this had something to do with sticky-ness, tried
getting a specific
revision.  This brought the correct revision number into my
sandbox, but
then left a sticky tag (either date or number; I tried both)
on the file.
No further changes could be committed.  I then cleared the
sticky tag using
CVS update -A and was again "rolled back" to a
revision that was not the
latest revision. (i.e. revision 1.1 in my previous
example.)

I'm not sure what to do at this point as I can't get CVS to
give me the
latest revision of a file using a normal update.  This is
happening for
every developer on our team and is causing significant
problem when our
source tree is updated and local changes are being put in .#
files when
"roll backs" happen.  Can anyone could shed some
light on this problem?

Thank you.
 
Brandon Frost

_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

On Tue, 20 Mar 2007 11:15:02 -0700, "Brandon
Frost"
<bfrosthcgsoftware.com> wrote:

>Update:
>In desperation, I went to the server that runs CVSNT and
stopped and
>restarted both CVSNT services.  This seems to have
resolved the issue.  I
>can now do a regular CVS update and get the latest file
revisions.  CVSNT is
>no longer stuck on an old revision number.
>
>Since I have a quick and easy solution, this issue is no
longer a huge
>problem.  However, CVSNT did somehow get in this state. 
I don't want this
>issue to recur.  Is this a known bug that may happen
again?  Will an upgrade
>to CVSNT version 2.5 fix this issue?
>
Where are you? In the USA?
In that case maybe it is caused by the recent DST change
imposed by
the government?

HTH

/Bo
(Bo Berglund, developer in Sweden)
_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

Yes, I am in the USA. 

I thought about this as a cause and I suppose it is
possible.  However, the
time has only been adjusted by 1 hour.  I tested this
problem on files that
were committed last week and was still getting the issue. 
If the time/date
stamp on the files caused this problem, you'd think the
problem would only
last for 1 hour and then resolve itself on each file.

Regardless, as soon as I cycled the services, the problem
disappeared on all
files.  Thanks for your suggestion.

Brandon Frost

-----Original Message-----
From: cvsnt-bouncescvsnt.org [mailto:cvsnt-bouncescvsnt.org] On Behalf Of
Bo Berglund
Sent: Tuesday, March 20, 2007 11:43 PM
To: cvsntcvsnt.org
Subject: Re: [cvsnt] UPDATE Does Not Return the Most Recent
Revision

On Tue, 20 Mar 2007 11:15:02 -0700, "Brandon
Frost"
<bfrosthcgsoftware.com> wrote:

>Update:
>In desperation, I went to the server that runs CVSNT and
stopped and 
>restarted both CVSNT services.  This seems to have
resolved the issue.  
>I can now do a regular CVS update and get the latest
file revisions.  
>CVSNT is no longer stuck on an old revision number.
>
>Since I have a quick and easy solution, this issue is no
longer a huge 
>problem.  However, CVSNT did somehow get in this state. 
I don't want 
>this issue to recur.  Is this a known bug that may
happen again?  Will 
>an upgrade to CVSNT version 2.5 fix this issue?
>
Where are you? In the USA?
In that case maybe it is caused by the recent DST change
imposed by the
government?

HTH

/Bo
(Bo Berglund, developer in Sweden)
_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt

On Wed, 21 Mar 2007 07:28:32 -0700, "Brandon
Frost"
<bfrosthcgsoftware.com> wrote:

>Yes, I am in the USA. 
>
>I thought about this as a cause and I suppose it is
possible.  However, the
>time has only been adjusted by 1 hour.  I tested this
problem on files that
>were committed last week and was still getting the
issue.  If the time/date
>stamp on the files caused this problem, you'd think the
problem would only
>last for 1 hour and then resolve itself on each file.
>
>Regardless, as soon as I cycled the services, the
problem disappeared on all
>files.  Thanks for your suggestion.
>
That was just a shot in the dark, really....

But I have also seen this behaviour using an older version
of CVSNT on
the server and a non-matching also older CVSNT client. But
not as old
as 2.0.58...

This issue went away after CVSNT upgrades but I don't
remember when.

HTH

/Bo
(Bo Berglund, developer in Sweden)
_______________________________________________
cvsnt mailing list
cvsntcvsnt.org
h
ttp://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt