Project Directory Structure: Feedback Please

[Brian Chirgwin]

Attached is an RTF document that has a directory structure for the project. I am looking for feedback. When I set up the SVN repository I'd like to add the project directory structure as a starting point.

Also contains details of automated testing.

Please review and provide feedback.

[StanHelton]

Hello Brian,

I found the RTF informative. I think we should draw attention to the ../doc/programmer and the /doc/user directories where you get a good overview of what the system will do. Of course everyone should at least browse the rest of the directories.

I'm not sure whether I prefer the 'no-branch' option or the 'branch-when-necessary' option. Depends on how many of us have experience with the system and who has full commit privileges?

Question for everybody:
How many of you have used either CVS or SVN before?

Thanks
Stan

[Brian Chirgwin]

Hello Brian,

Question for everybody:
How many of you have used either CVS or SVN before?

Stan

Or any other Source Code Management product?

[Brian Chirgwin]

I'm not sure whether I prefer the 'no-branch' option or the 'branch-when-necessary' option. Depends on how many of us have experience with the system and who has full commit privileges?

Stan

Stan,

My mind is open to either, but I am leaning toward branching. Here's my reasoning:

• Branching allows a developer to branch off and commit non-working code into the branch without breaking the main line.
• The branch developer can and should update from the mainline frequently. This will reduce a large number of compile issues when the developer thinks they are done. In other words, the user can update there branch with the latest main line at anytime and multiple times. This should be done before merging back into the mainline.
• The main line should always compile and always past all tests. Without branching, this means developers can't check in code until their code works.
  Of course, if developers are working in small increments, they could check in every small step. This would also require developers to update (get the latest) from the mainline often as well. Not a problem and should be done either way.
• Keeping the main line locked to check out (modification) to all developers accept one or two, will allow control of what goes into the main line. The one or two developers can make sure code is standardized, compiles, runs, tests complete, before putting it in the mainline.
• As I have stated I have only used SVN in a single user environment so I have not run into branch issues. I've used branch in a single user environment as it is a useful tool. I would like the experience of using branching in a many developer project. That said, non-branch experience would also be a learning experience.

SVN does not prevent two people from checking out the same file. A file frmMain.bas can be checked out by everyone and modified. When one commits the file, merge occur. This process is very similar to branch and having to perform a merge. If there is a collision (Two people have modified the same line of code, a decision must be made as to which should be kept before commit can occur). I believe with branching, this would be less burdensome as the developer can update from the mainline at there convenience and not every time they check there code.

Anyway, as stated I am leaning toward using branching, but can easily be convinced otherwise. This is all theory until it is tried.

I'm willing to go either way.

[StanHelton]

Very convincing arguments. Unless somebody objects lets use branching.

Since you have the server and are more familiar with this, you should be one of the developers with full commit privileges. I would like to be the other, but I have a learning curve to deal with before I'm ready.

Stan

[Fred Harris]

I've no knowledge or experience with any of these issues. I've always worked in an environment where I'm a lone coder in an agency of non-programmers, so I've never had to deal with anything other than keeping my own code straight. So I've a lot to learn here.

[Rodney Hicks]

Brian,

I too have been a lone programmer so I will go along with what those who are familiar with teamwork are most familiar with.

Correct me if I'm wrong, but shouldn't the "\bas\" in the very last line in your Directory Structure be "\apps\"?

The test results directory.
Could we also include a .txt version of the HTML document?
One of the standards I will be proposing is that all documents come in a .txt format so it can be loaded in the PB IDE. Syntax highlighting is disabled if you save a document under "SAVE AS" with .txt selected. This way while we may have a collection of .doc, .rtf, .html, etc., if they all exist in .txt we can all access them with one common program. Not quite as pretty, but no reason to miss anything either.

The following quote concerns me a little.

If this is possible, I think the test status page will become public so people can watch progress.

I'm not quite sure what you mean by public. By the time the future gets here I might know, though.

With the considerations mentioned above, what you have proposed looks good regarding the directory structure. Will it be etched in stone so to speak or will you be able to add additional subdirectories without much difficulty?

Stan is not the only one with a learning curve.

Rod

[Brian Chirgwin]

Brian,

I too have been a lone programmer so I will go along with what those who are familiar with teamwork are most familiar with.

Correct me if I'm wrong, but shouldn't the "\bas\" in the very last line in your Directory Structure be "\apps\"?

Correct. Good catch.

The test results directory.
Could we also include a .txt version of the HTML document?
One of the standards I will be proposing is that all documents come in a .txt format so it can be loaded in the PB IDE. Syntax highlighting is disabled if you save a document under "SAVE AS" with .txt selected. This way while we may have a collection of .doc, .rtf, .html, etc., if they all exist in .txt we can all access them with one common program. Not quite as pretty, but no reason to miss anything either.

Yes, I text file would be written as well. The batch test runner will display the results so you may never need to load the text file, but it will be there.

The following quote concerns me a little.


I'm not quite sure what you mean by public. By the time the future gets here I might know, though.

I was thinking it would be a web page for anyone to view without requiring a password. For anyone to follow progress. Of course, we could password protect it and only allow those we want to see it.

With the considerations mentioned above, what you have proposed looks good regarding the directory structure. Will it be etched in stone so to speak or will you be able to add additional subdirectories without much difficulty?

Directory structure can be changed, but will require some changes other than just modifying a directory name.

1. Change of directory/filename through SVN - Not difficult
2. Change of test runner code to get test input and expected results from new paths

Stan is not the only one with a learning curve.

I've thought of this I'll be developing directions and a little test project for everyone to play with to get everyone familiar with the software. I'll also create a repository for everyone to test ideas.