问题
We are moving to SVN from VSS and are debating the project structure. We are debating two proposals displayed below.
No. 1 seems simpler for development support since a Project release version is tied to a tag and the developer would only need to perform an update on that tag to immediately get to work.
No. 2 insures that all Projects and Dependencies can be developed independently but building a particular release version means knowing the tags of the Project and all it's Dependencies.
Are there obvious comparative benefits between the two? Any gotchas in the two structures? or are there better structures out there?
1.
Development
+ trunk
Project1
Project2
Dependency1
Dependency2
Dependency3
+ branches
+ tags
2.
Project1
+ trunk
+ branches
+ tags
Project2
+ trunk
+ branches
+ tags
Dependency1
+ trunk
+ branches
+ tags
Dependency2
+ trunk
+ branches
+ tags
Dependency3
+ trunk
+ branches
+ tags
回答1:
In general, I recommend having projects remain separate as much as makes sense (your second option). This will generally promote reuse. (If I only want Dependency2, I don't need to bring an entire other project in order to get to it.)
However, you have to be smart about what your dependencies are really going to be doing. For example, if Dependency2 is only going to be a dependency for Project1, then it should probably just exist within Project1's source structure. (Note: I do not mean have separate branches and tags for the Dependency - I mean have it be in a different package, or another subproject within Project1.)
If you want to make a project a reusable library within your organization, then have it as a separate project completely so you don't introduce unnecessary co-dependencies. And, I would encourage your development team not to check out a dependency and work alongside that. Instead, build the dependencies and use them as a binary library. This way, whoever checks out a Project to work on it will always have the latest library dependency that they need for the application. If an update is needed, then you can worry about checking out the Dependency and building it. (Or, even better, have a location where project teams can release the latest libraries as binary files.)
Update on Versioning of Project and Dependencies If you go with the #2 route, and have separate Project and Dependencies, your versioning actually becomes very simple. Here is an outline of how it might work.
- Team A is working on Project1.
- Team B is working on Dependency1 which Project1 depends on.
- Whenever Team B finishing their work, they build a release of Dependency1 (a binary - perhaps a DLL, or a library, or something along those lines). They can also tag their project at this time. The binary name may be: Dependency1-v1.0.0
- Team A takes the binary release of Dependency1-v1.0.0 and includes it in their project. (Typically, binaries are kept in a /lib folder or something like that within the project.)
- Whenever Team A finishes their work, they can release their project and tag their project as well.
Note that, at no point, does Team A check out the source code from Dependency1 and bring it into their project. This allows development of the two projects to remain separate so that there is autonomy between the development teams. Team A can use the binary for as long or as short as they like. If they want an updated version, they go get the latest release from Team B.
This process is not really much different from what you would do if you were using a library from an outside source. You have no control over how they version their library, so you just grab what you need for your project and update when you feel is necessary. You keep the binary within your own project structure so that you can always rely on it.
回答2:
Go with #2:
Project1
+ trunk
+ branches
+ tags
Project2
+ trunk
+ branches
+ tags
Dependency1
+ trunk
+ branches
+ tags
Dependency2
+ trunk
+ branches
+ tags
Dependency3
+ trunk
+ branches
+ tags
With projects that must reference other projects, check out the section on "SVN Externals". This allows you to set a particular SVN revision of a dependency as the value used in another project.
回答3:
I'd personally go with #2. We did that at my previous company and it worked very well. It isolated each project so you could easily just view its history with regards to branching and tagging without any additional effort. The ability to just check out a project and get all of its branches, tags, and trunk is a nice ability when tracking differences locally as well.
回答4:
Thank you to everyone for helping me understand this so much better!
@JasCav, I especially thank you for your explanation of how to think about how "dependent" a particular dependency is. I have both, so I think the structure implied would be:
Project1
+ trunk
SubPrjFor_Prj1
LibraryExternalRefs
Dependency1_DLLOnly
Dependency2_DLLOnly
Dependency3_DLLOnly_NOT_SHARED_UsedOnlyByPrj1_ONLY_HERE
LibraryWithSource
Dependency4_UsedOnlyByPrj1_NOT_SHARED
Source_SubFolder1
Source_SubFolder2
+ branches
+ tags
Project2
+ trunk
SubPrjFor_Prj2
LibExternalRefs
Dependency1_DLLOnly
+ branches
+ tags
Dependency1_UsedByBothPrj1Prj2
+ trunk
Dependency1_DLLOnly
+ branches
+ tags
Dependency2_UsedByPrj1SoFar
+ trunk
Dependency2_Source_SubPrj1
Dependency2_Source_SubPrj2
+ branches
+ tags
Of course, I have elided the matching structures for the trunk/branches.
ps @JasCav, I apologize for not voting you up nor putting this item under your comment; I apparently don't have points to do those things, which does not make much sense to me. I thought logging in would enable me to comment and thus track Stackoverflow items of interest, but I guess not.
Edit: fixed formatting and expanded example to 4 dependencies.
回答5:
Instead of keeping just one repository, as all these structures suggest, on another post here, VSS to SVN - Repositories , the users suggest having one repository per team. That way the SVN revision number will increment only upon commits made by an individual team.
Have any of you tried that method? Is there extra overhead work involved?
I would like to keep the codebase clean with the minimum amount of SVN administration work, as in my case I will likely be doing it :).
回答6:
If all the Projects are part of the same Solution or product, then I would go with approach #1.
I use the following structure:
TRUNK
--Build
--Product
----Source
------Project1
------Project2
------Project3
----Test
--ThirdParty
The ThirdParty directory is for non-source code dependencies such as libraries or APIs.
My guidance is rooted in a new developer being able to get latest from the Trunk and getting everything (and I mean everything) they need to immediately build the product. Chasing down references is a big waste of time that can be easily avoided.
回答7:
My experience is it's just a matter of convention. And the SVN Book does not have a problem with either.
In one of the projects, the team was using ANT build and was more emphasis flat structure. We were having approach #2. With one master build-script. It was alright when I was working on that and we were having no problem.
The current project involves Maven build, so over code is by default has #1 structure with one parent and under that, dependencies and modular projects. In SVN, we follow approach #1. But, if an entirely new project is going to start, we will have mix of #1 and #2 in over layout. Something like this:
Project1
trunk
project1A
project1B
dependency1C
dependency1D
branches
tags
Project2
trunk
project2A
dependency2B
branches
tags
To summaries, I would like to keep my repository logically separate. So, to answer your question -- I would prefer approach #2.
Edit#1: the SVN-Book URL is fixed
来源：https://stackoverflow.com/questions/4629670/svn-project-structure