[Top][All Lists]

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

FW: Another bug in "admin -m"

From: Rodolfo Schulz de Lima
Subject: FW: Another bug in "admin -m"
Date: Sat, 18 Oct 2003 17:38:33 -0300

> And I found an additional that is more collateral damage. Previously,
> without the force tag match argument, rev would always return a version
> that existed. When forcing the tag to match, it might either return NULL
> meaning that there was no match or return a rev of a tag that did not
> exist. So, restoring the ':' was necessary, but so was checking that
> findnode did not return NULL.

Yes, it's better to be safe, in more when programming in C (yes, I'm a C++
> Oh well, at least we have fixed them now. Please let bug-cvs know if you
> run into any more bugs in cvs.

Well, since you've mentioned that, I've a doubt, but I don't know if it's a
bug or not. When you try to commit a file whose only thing that's changed is
its timestamp, cvs doesn't do anything (even an error message isn't
displayed), and the file remains marked as changed, i.e., CVS/Entries isn't
updated to the timestamp of the file in repository. You need to do a cvs
update -A <filename> to make the change. Is this the correct behavior,
albeit a strange one? 

I've come into this when merging to the main branch a new version of a new
version of a library in a vendor branch. When doing the import of the new
version, all files are marked as "C", requiring me to do a merge to the main
branch. When doing "cvs commit" to check in the merge, only the files with
no change (but different timestamps) remains marked as changed.

Rodolfo Lima.

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.516 / Virus Database: 313 - Release Date: 1/9/2003

reply via email to

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