solving the selective update of non-existent directories

[Martin d'Anjou]

Hi,

I have this problem:
http://lists.gnu.org/archive/html/info-cvs/2001-07/msg00142.html

Which is represented here by a short example. We want file "f4" under
d1/d2/d3/d4, but we only have up to d1/d2 in the "local copy". Instead of
fetching the file, CVS complains:

$ cvs up -r 1.1 d1/d2/d3/d4/f4
cvs [update aborted]: no such directory `d1/d2/d3/d4'

A solution is to create the missing directory tree, and manually add
CVS/Repository and CVS/Root:

$ mkdir -p d1/d2/d3/d4
$ mkdir d1/d2/d3/CVS
$ mkdir d1/d2/d3/d4/CVS
$ echo "bozo/d1/d2/d3" >d1/d2/d3/CVS/Repository
$ echo "bozo/d1/d2/d3/d4" >d1/d2/d3/d4/CVS/Repository
$ echo "/work/cvs_database" >d1/d2/d3/CVS/Root
$ echo "/work/cvs_database" >d1/d2/d3/d4/CVS/Root
$ cvs up -r 1.1 d1/d2/d3/d4/f4
cvs update: cannot open CVS/Entries for reading: No such file or directory
U d1/d2/d3/d4/f4
$

CVS apparently does not care that CVS/Entries is missing, and happily adds
it. Since all the variables are known, this can be automated easily.

Anyone sees anything wrong with this solution?

Martin

[Arthur Barrett]

Martin,

Post by Martin d'Anjou
Anyone sees anything wrong with this solution?

All the files in the CVS directory are internal CVS files and you
shouldn't be making assumptions like you are - much better just to get
CVS to create them for you.

Maybe if you describe what business problem you are actually trying to
solve someone will have a solution for you. Remember that CVS has been
around for well over 20 years - there is almost zero chance that
whatever problem you are trying to solve hasn't been encountered and
solved already.

Regards,


Arthur Barrett

[Martin d'Anjou]

Post by Arthur Barrett
Maybe if you describe what business problem you are actually trying to
solve someone will have a solution for you. Remember that CVS has been

The problem is:
http://lists.gnu.org/archive/html/info-cvs/2001-07/msg00142.html

Martin

[Arthur Barrett]

Martin,

Post by Martin d'Anjou
http://lists.gnu.org/archive/html/info-cvs/2001-07/msg00142.html

CVS 1.11.0 is very very old and I believe has security issues.

My question is WHY do you want to update file1.txt instead of simply
updating the entire directory dir1 or dir2? The second example where you
want to get dir2/x/y/file1.txt seems particularly arbitrary, if your
sandbox is missing dir2 then surely you need ALL of dir2 (eg: if you
need dir2/libxml2/include/libxml2.h then you are also likely to require
dir2/libxml2/lib/libxml.a).

Regards,


Arthur Barrett

[Martin d'Anjou]

Post by Martin d'Anjou
http://lists.gnu.org/archive/html/info-cvs/2001-07/msg00142.html

... [deleted stuff]
My question is WHY do you want to update file1.txt instead of simply

Sometimes, files in the same directory are not dependent on each other.
What happens in that users submit only a subset of the files in a
directory for the robot to update, but not all the files.

updating the entire directory dir1 or dir2? The second example where you
want to get dir2/x/y/file1.txt seems particularly arbitrary, if your
sandbox is missing dir2 then surely you need ALL of dir2 (eg: if you

Well... this assumption does not work for our flow. I do not need all of
dir2, in fact, quite the contrary. A robot is told what new files to pull
in, and those are the files that need to be pulled in, nothing more.

Regards,
Martin

[Arthur Barrett]

Martin,

Post by Arthur Barrett

Post by Arthur Barrett
updating the entire directory dir1 or dir2? The second

example where you

Post by Arthur Barrett
want to get dir2/x/y/file1.txt seems particularly arbitrary, if your
sandbox is missing dir2 then surely you need ALL of dir2 (eg: if you

Well... this assumption does not work for our flow. I do not
need all of
dir2, in fact, quite the contrary. A robot is told what new
files to pull
in, and those are the files that need to be pulled in, nothing more.

How is this communicated to the robot?

Off the top of my head if I did need to do such a thing I'd use a tag -
then you will get the result you want because the tag will only be
applied to the files you want to update.

I mostly use CVSNT (free/GPL runs on linux just like CVS) which also has
another way of solving the issue: an automatic tag applied to every
commit (a commitid), this may also be in CVS 1.12 but I'm not sure.
Just out of curiosity I tried your first suggested command (checkout)
and it works on CVSNT - so obviously we considered that a 'bug', but I
don't know if CVS 1.x has a similar patch - again if you are using
1.11.0 it is very very old.

rmdir /s /q cvsnt

cvs -d :ssh:cvs.cvsnt.org:/usr/local/cvs co
cvsnt/cvsapi/win32/FileCompat.cpp
U cvsnt/cvsapi/win32/FileCompat.cpp


Regards,


Arthur Barrett

[Martin d'Anjou]

Post by Arthur Barrett
How is this communicated to the robot?

By telling the robot the filename and the version number. I have created a
small self-contained example which reproduces the problem as clearly as I
can:

#!/bin/bash

# Create the CVS repo
export CVSROOT=~/cvs_repo
mkdir $CVSROOT
pushd $CVSROOT
cvs init
popd

# Create something to import
mkdir -p foo/d1/d2/d3/d4
pushd foo
touch d1/f1 d1/d2/f2 d1/d2/d3/f3 d1/d2/d3/d4/f4
cvs import -m "Import" foo mdanjou start
popd
rm -rf foo

# First checkout
cvs co foo

# Tag the "approved" files only
pushd foo
cvs tag GOOD_CODE d1/f1 d1/d2/f2
popd

# The robot starts off with the approved files
cvs co -d robot_sandbox -r GOOD_CODE foo

# The robot is told "get release x.y of file d1/d2/d3/d4/f4"
# the exact value of x.y is irrelevant, it could be anything
# as long as it exists in CVS. In this example we only have
# version 1.1, so we use that for now:
pushd robot_sandbox
cvs up -r 1.1 d1/d2/d3/d4/f4 ## THIS FAILS, WHY?
popd

Why does this command fail? Is this a bug?

BTW, I see commitid in the NEWS for cvs 1.12.12, but 1.12 is not declared
stable. I use CVS 1.11.17 (client/server) on linux.

Thanks,
Martin