"Ian Scott" <ian.m.scott@...> writes:
> 1. We will lose a lot of CVS log information (or at least obscure it). You
> could wait until SF starts to use subversion, at which point this sort of
> change will be fully versionable. - That will probably be over a year
I think this is an important point. Every file rename we do "deletes"
the log. This is bad enough for one file here and there; doing it for
all of gel, oxl, mul, rpl, tbl is, IMHO, unacceptable.
An option may be to request the SF team to move the files in the
repository for us. That would imply locking down the repository for
however long it takes them to process this request (assuming they'll
do such a thing).
Another option may be to get the tar.gz of the whole repository,
manipulate it, and ask SF to replace the old with the new. (Again,
with a repository lock-down while this was being done.)
> 2. If you are going to change the structure, I would like to suggests
> something else at the same time - Removal of all CVS controlled files from
> The fact that they are there makes it a real pain to manage building VXL +
> private libraries in the same tree. CVS gets confused by the VXLROOT/CVS
If you don't want a CVS directory at VXLROOT, how do you check out the
source? Multiple checkouts?
We haven't run into this problem over here. We use FreeBSD, Linux and
Windows. The cvs clients are from FreeBSD, Linux, Windows/DOS and
Windows/Cygwin. The personal checkouts look something like
vxlroot +-- CVS (refers to SF)
+-- vcl +-- CVS (refers to SF)
+-- vxl +-- CVS (refers to SF)
+-- local +-- CVS (refers to local cvs)
When we do a cvs update at the vxlroot level, the cvs clients do one
of two things:
1. Update the SF stuff, and mark "local" with a "?", and ignore it (Windows)
2. Recognise the different repository, and make a new connection (Unixen)
Is your behaviour different, or am I talking about a different problem?
> What we do here at Manchester in our own libraries is relegate all the
> control files to a sub-directory (config.cmake would be an appropriate place
> in VXL). Then when someone checks out the code for the first time, they
> write a small control file which merely references main one which stays
> under CVS control in the config directory.
If we do something like this, we must ensure that:
1. The "configure" stuff is independent of CMake. Some people still
don't use CMake, and it's good to leave that option in place.
2. The naming of the directories should also maintain that
independence. Right now, the config.cmake directory contains *only*
CMake related stuff.
In the original post, Geoff mentioned contrib to match other Open
Source projects. I'll point out that many people expect a ./configure
at the top level. However, we have to keep in mind that many of our
assumptions in vxl don't match other projects. We recommend the use of
CMake. We haven't, at least in the beta release, provided any other