SVN good practice (branches)

Our application is currently made up of two big entities: C# ASPX files, and RPT report template files.

ASPX files are developed by someone, and the RPT files are developed by someone else.

Both worlds are not in sync. For example, you could have 10 new versions for the RPT templates, while only one is done on a C# file.

Is there a way to separate those two logical streams of development part of the same project in SVN? Should everything be kept in the same repository? Would SVN开发者_如何学编程 branches be a good application for this?

The way I'd see it would be to have all directories in the same application as such,

• /ModuleA/Main.aspx
• /ModuleB/Admin.aspx
• /ReportTemplates/Generic.rpt

Any guidance would be appreciated!

Thank you

If they are part of the same project, they should be in the same repository. And you wouldn't need to branch really; one person can work on RPT templates, another person can work on ASPX files, and everyone would get each other's changes.

Branching would come into play if you had a need to maintain two or more lines of development on the same files. But what you're describing is the standard, normal use case for Subversion and does not require using branches.

Files that belong to the same project should go into the same repository, unless some of the files can be used in another project as well (then you'll have to consider creating a separate repository for common code and use the externals feature to link in parts of it).

Branches have nothing to do with how you divide your code. Branches are for following changes done to code over time outside of the main trunk, allowing the developer to periodically check-in into the branch.

If the ASPX and RPT files are dependent upon each other (e.g., a change in one could break the other), and the people doing the commits are not verifying the functionality of the app before committing, you may in fact want separate branches, so that you can isolate the potential impact of a breaking change. Then you would have a person designated as the integrator who would do the merge and confirm functionality before committing.

In a normal workflow however, these changes would all be committed to the same repo and branch ,and functionality would be confirmed reasonably well before committing, ideally via unit tests that run along with your build script.

This is not a good use for branching. Branching is more like when you have code that is the same, yet different(either for legacy or release or whatever)

I say that you should just put all of these files in trunk and not worry about branching until you need to make a breaking change or a branch for a release or similar.