Posted by william on Fri Mar 19 14:26:33 1999
In Reply to: Re: Re: Sys Admin - where do we put projects posted by Myles on March 19, 1999 at 13:27:35:
| Distribution: | paneris@i-way.co.uk |
|---|
multiboard@paneris.co.uk writes:
> At present the CVS root is /usr/cvsroot. Can we checkout projects/bloggs-plc?
> I was under the impression that you (initially) had to check out
> a top-level module (i.e. projects, nots projects/bloggs-plc). I'm
> wrong, I assume.Hmm, it seems to work, except that it can be convenient to use the -d
option to cvs checkout. I think the idea with CVS is that
subdirectories are (sub-)modules in their own right.> BTW, how do you find out what modules you have in your CVS repository
> using a cvs command (i.e. without cd'ing over to the repository
> and looking at the directories!)?You can't, can you? Interesting ...
> Sounds sensible. With java the source and .class files can live
> together quite nicely, so we might not need the dist directory
> often (we wont necessary need to distribute the code)...Actually I hate that. It just clogs things up. When I do
mixed-language programming, I have a Java-style list or tree of
packages, and put all the sources, of whatever language, together. I
have a separate tree for computer-generated sources, if any, and a
separate tree for each kind of object code: Java (and ML) bytecode,
Linux-i586 objects, sunos5-sun4 objects ...That's extremely easy to achieve with the -d option to javac.
Apart from anything else it's nice to be able to do
cvs add `find` without having to exclude non-sources
in some ghastly config file.> Agree. I'm quite on for that - sticking any common code into a project.
> It helps in moving the code (e.g. installing it live). It's just
> not very nice :-)My feelings too.
However here's a "right" way of doing it that *might* not be too
painful: whenever we make a "release" of anything, we do a cvs tag of
the entire repository to ensure recoverability. We get round the
package-copying problem as follows: rather than doing
CLASSPATH=../../administration or whatever, we do
CLASSPATH=dependencies/administration, where dependencies is a
directory containing symbolic links to the libraries we have used.
Of course it's not automatic or foolproof ...> OK. As I say, the cvsroot is different at the minute. I'm assuming that
> no-one would have a problem making links, e.g. from /usr/local/sugar
> to /usr/local/packages/inst/projects/sugar-#.## (I'm not really sure we
> need the (customer) dir in there...?)Nor am I, it was just a thought ...
> We don't need the links from httpd so much since we can alter classpath
> and use virtual servers...I don't like classpath or virtual servers, or any kind of environment
variable or configuration file. I think everything should be in the
file system. But that's an aesthetic thing.> For ease, we should set up a link from /usr/local/sugar to ../inst/projects/sugar-#.##
Fine, although if you choose the names right they are very easy to
type with tab completion ...> Similarly for shared code (e.g. org.paneris.utils) where I suggest we use
> ../paneris/java (or ../paneris/perl)Well I'd still rather group everything by functionality. I don't want
to see files related to the same library/project, which are
potentially in different languages, split in such a way that they don't
have a common root.We should aim for a situation where "install X" is a matter
of "cp -r X ..." plus running a script to make a few links.Perhaps we can adopt the Java naming convention for everything,
and put the whole caboodle in/usr/local/packages/inst/paneris/org/paneris/adminsystem
---*.pm, *.class and *.html etc. etc. etc.
Certainly I feel very strongly that that's what we should do with the
*sources*. (Hmmm, I suppose that means that for Java-friendliness we
want to stick org/paneris on the front of everything ... but I'm on
for that, why not?)