cvs update -d -l newdir corrupts local checkout

[Jonathan Larmour]

Hi all,

I've found a problem when using cvs update -d -l to update a new 
directory. It fails to either do the right thing, or report an error, and 
instead leaves the local checked out tree in a broken state.

e.g. suppose someone somewhere adds a directory foodir/bardir/bundydir 
into the repository
If I am in foodir/ and bardir exists but does not yet contain bundydir in 
the local checkout then I can type:

  cvs -f update -d -l bardir/bundydir

then it appears to work *but* foodir/CVS/Entries.Log contains:

A D/bardir////
A D/bardir/bundydir////

which is not correct.

What's more if I then do just
  cvs update
now, I get:
cvs update: Updating .
cvs update: Updating .
cvs update: Updating .
[snip same line repeating for a long time...]
cvs update: Updating .
cvs update: cannot open .cvsignore: Too many open files
cvs update: cannot open .cvswrappers: Too many open files
cvs update: Updating .
cvs [update aborted]: cannot open CVS/Root: Too many open files

The only fix is to manually remove the line in CVS/Entries.

At the same time, foodir/bardir/CVS/Entries doesn't contain an entry for 
bundydir.

There are plenty of other ways to expose this problem. Simply trying to do:
cvs -f update -d -l ./bardir
will also cause problems.

The solution is either to make e.g. cvs update -d -l bardir/bundydir be 
the logical equivalent of:
cvs -f update -d -l bardir
cd bardir
cvs -f update -d -l bundydir

Or just forbid the use of update -l on subdirectories. Additionally "./" 
should be eliminated in supplied paths. I think the first approach makes 
more sense really, but then without a patch what position am I in to say :).

Hope this report helps, let me know if you want any more info.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine