Re: slightly off topic - Directory Structures

[thomas . maciejewski]

|---------+---------------------------------->
|         |           Karl-König Königsson   |
|         |           <karl-konig.q.konigsson|
|         |           @posten.se>            |
|         |                                  |
|         |           06/23/2003 08:31 AM    |
|         |                                  |
|---------+---------------------------------->
  
>------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                 |
  |       To:       address@hidden, address@hidden                              
                             |
  |       cc:                                                                   
                                                 |
  |       Subject:  Re: slightly off topic - Directory Structures               
                                                 |
  
>------------------------------------------------------------------------------------------------------------------------------|










**********************************************************************
The information contained herein is confidential and is intended solely for the 
addresse(s).  It shall not be construed as a recommendation to buy or sell any 
security.  Any unauthorized access, use, reproduction, disclosure or 
dissemination is prohibited.
Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume 
any legal liability or responsibility for any incorrect, misleading or altered 
information contained herein.
**********************************************************************


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

address@hidden wrote:
| <Project Name>/build ? This is where code get built. The base of this
| directory should mirror src.  This should only be written to by make or
| make substitute ( i.e. ant )  These files should not get checked in.
Only
| the directory stubs should be check in

There is no need then to have this version controled, is there? You would
therefore not need to store it in CVS.


Correct.  I marked this as off topic as it is somewhat related to CVS but
the questions is bit broader than CVS.
I am just curious on how people have their directories set up.
Some of these directories may be saved under CVS others may not be





It makes sense from a build perspective but I would suggest that you let
Ant
create the build structure for you and have a "clean" task remove it after
you
are done. You could also have a ".cvsignore" file on top that specifically
instructs CVS _not_ to take "build" into account.

| <Project Name>/lib ? This is where any libraries or external dependencies
| that are needed for this project are stored.

Having a "lib" like this is always a ballance act -- it is generally not a
good
idea to store binary data in CVS unless it is _really_ needed.

Is this just a disk space issue?


On the other
hand, you could have jar files that are external to your project that might
change in the future, and then it makes sense to keep them in CVS. This is
something to think about of course.


This is what I was thinking ... that if you want to build exactly what is
in production than jars and other lib or dependencies need to be included.
We were actually contemplating using CVS as a mechanism to store what is in
production including all of the executables ...
In our staging are we would set up what we wanted to be in production and
then when we were happy we would save all of these files into the
production project ... then would go to our production box and to  cvs
update and we should then have a production environment ...

This would make any rollbacks very easy because we could always just cvs
update -r to get back to a certain production environment.
Again we were just contemplating this ... any comments?




Generally speaking: external binaries that are crucial to the project
should
probably be stored in CVS, all others should be handled otherwise. You
could,
for instance, have a special ant task that copies such files from a network
repository. If you have the name of the repository reflect some sort of
version
you might even handle version control thusly:

- - all binaries are stored in directories that reflect the version
- - Ant handles the copy stuff, new versions are added by changing the
build.xml
file, thus providing the traceability needed (but you may not delete old
version directories, of course)

| <Project Name>/config ? This is where any configuration files are stored.

Good thing. Again, let Ant do the copying and building and you keep track
of
configuration. Easy to find the config files this way, and still be able to
handle a complex system. Needs fiddling with Ant but you have to do that
anyway.

| <Project Name>/Common ? This is a link to the Common Project.  This link
is
| provided as a convenience when doing development.  This directory should
| only be used in development and not in production

I don't get this one.

Well this goes back to one of my earlier posts where if you have common
reusable code where does it go and how is it handled by CVS.
for example StringUtils.java or something like that?




| <Project Name>/docs ? All Documentation for the Project
|
| <Project Name>/test ? an area for any test scripts or anything related to
| testing this project

Well, sort of. If you are doing Java you might want to check out JUnit. It
would then be a better plan to add a junit directory/package for each
package
in your project. This would let you do your testing fairly easily and also
possibly remove the need for a specific test directory.


I do use JUnit ... but I always feel that there should be a test suite
especially when you are making changes to common code.  This way you can
see if you have broken anything.  Also I am not sure if any of you have
used "Tinderbox" which is an automated build mechanism.  We would have
automated builds and then part of the build mechanism would be to run our
test suite.  This worked nicely as you always new that the current code in
CVS production not only build but passed all of your automated tests






| **********************************************************************
| The information contained herein is confidential and is intended solely
for
the addresse(s).  It shall not be construed as a recommendation to buy or
sell
any security.  Any unauthorized access, use, reproduction, disclosure or
dissemination is prohibited.
| Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall
assume any legal liability or responsibility for any incorrect, misleading
or
altered information contained herein.
| **********************************************************************

Yeah, right... Maybe you should get rid of this. It just does not make
sense on
a mailing list, but that has been pointed out in excruciating detail
elsewhere.


Thank you for handling this maturely ;-)  I actually have no control over
this.




"Share and enjoy", would perhaps be a better alternative... :-)


Unfortunately in a sue crazy world people need to CYA ... kind of like the
big sign on the train that says please do not step off of moving train.
Or the disclaimer on mcdonalds coffee cups warning of hot beverage.


DISCLAIMER ABOUT DISCLAIMER :
please no further flames ....





Cheers!

             Karl-Koenig Koenigsson


- --
CONG (n.)
Stange-shaped metal utensil found at the back of the saucepan cupboard.
Many
authorities believe that congs provide conclusive proof of the existence of
a
now extinct form of yellow vegetable which the Victorians used to boil
mercilessly.
(The Meaning of Liff, Douglas Adams)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+9vMmiIlor53vvbcRAsgvAJ9b3LkVOt66wb92Y47tluuFcSszzQCfYs2x
rUq0z8mljdvpWvaBW3KsR+U=
=wldr
-----END PGP SIGNATURE-----