What is the "best" way to store scripts?

I have hundreds of scripts for testing a component. Each of these scripts contain a set of subscripts and individual records.

Subscripts can be used in multiple TC_Level scripts and even in other subscripts.
Every script has a unique name.

Example:

TC_1
  |  
 (1) Subscript_a  
  |  |  
  | (1) Record  i
  |  |  
  | (2) Record  ii
  |  
 (2) Subscript_b  
  |  |  
  | (1) Subscript_c
  |  |  |
  |  | (1) Record_i  
  |  |  |  
  |  | (2) Record_iii  
  |  |
  | (2) Record_ii  
  |  
 (3) Record_iv  
  |  
 (4) Record_v  
  |  
  ...

I would like to

• store my scripts in a container.
• read them into a tree view within my script engine.

What type of container should I use?

Possible containers (but not limited to) : directory, database, XML file, spreadsheet, flat file, ...

Please, when making suggestions, also include a short sample (not necessarily code) of storage structure.

I have seen c# examples of populating treeviews form databases but I do not think I can use a reference to a parentID (for the subscripts) since a subscript can have more than one parentID.

From stackoverflow

• I would recommend to rely on a directory structure + version control system.

  It has many advantages:

  • version control helps you to keep your revisions and improves security
  • it is still accessible for you without any fancy tools
  • it's simple
  • it's pretty fast
  Michael Wells : The program we have originally used a directory for the scripts and we just read them in. The end users would very often forget to include a script when putting them in configuration management. They would not notice this until a week before the actual test occurs and hunt down the missing scripts. Then we put everything in a (poorly designed) database and now I have the chance to clean up by re-writing the interface (and data store).

• I would also recommend just using a directory structure with a consistent naming scheme. If you need to package up all the files, you might be able to just use "tar" (or some other archiving/zip tool).

  Michael Wells : configuration management would "see" through this and make us unpack and verify each individual script. ;)

• I agree a version control system and a file system is ideal.

  However I would also recommend that you break down each test case to contain a directory for each peice of additoinal data it needs. Most modern dat version control system support the notions of links and this would be an ideal use of them to make everything maintainable in the long term. These also play well with tar as is mentioned by another answer.

   Shared
   |    |
   |    Subscript_a  
   |    |
   |    Subscript_b
   |    |  
   |    Subscript_c  
   Test_Case_1
   |         |
   |         SUBSCRIPT_B_DIRECTORY
   |                             |
   |                             link to ../../Shared/Subscript_b
   |                             |
   |                             SUBSCRIPT_C_DIRECTORY
   |                                                 |
   |                                                 link to ../../../../Shared/scri_c
   Test_Case_2
   |         |
   |         SUBSCRIPT_C_DIRECTORY
   |                             |
   |                             link to ../../Shared/Subscript_c
   Test_Case_3
             |
             SUBSCRIPT_A_DIRECTORY
             |                   |
             |                   link to ../../Shared/Subscript_a
             SUBSCRIPT_B_DIRECTORY
                                 |
                                 link to ../../Shared/Subscript_b
  

  The same would apply to records. Its painful to setup but I believe that it will buy you the flexibility and maintainability in the long run of being able to mix and match your scripts and Test_Cases. You will have to deal with the extra level of indirection and a some environment variables such as $SHAREDTOP could isolate your scripts from being moved around. If you are windows you will only get the linkable feature from a good version control system. Again tar would even suffice on a UNIX box.

  Michael Wells : See the All comment above.