My team is considering to move from Clearcase to Subversion and we are thinking of organising the repository like this:
\trunk\project1
\trunk\project2
\trunk\project3
\trunk\staticlib1
\trunk\staticlib2
\trunk\staticlib3
\branches\..
\tags\..
The issue here is that we have lots of projects (1000+) and each project is a dll that links in several common static libraries. Therefore checking out everything in trunk is a non-starter as it will take way too long (~2 GB), and is unwieldy for branching.
Using svn:externals to pull out relevant folders for each project doesn't seem ideal because it results in several working copies - one for the project and one for each static library folder. We also cannot do an atomic commit if the changes span the project and some static libraries.
Sparse checkouts sounds ve开发者_StackOverflow中文版ry suitable for this as we can write a script to pull out only the required directories. However when we want to merge changes from a branch back to the trunk we will need to first check out a full trunk.
Wonder if there is some advice on 1) a better repository organization or 2) a way to merge over branch changes to a trunk working copy that is sparse?
Regarding #2
Even if it is possible to perform merges with sparse checkouts, I would not recommend this. Merges performed in incomplete or shallow working copies cause subtree mergeinfo to be created. Subtree mergeinfo gets to be a big nuisance over time.
See: Where Did That Mergeinfo Come From?
I recommend always merging from the root of the source branch to the root of a full, clean working copy of the target branch. After resolving any conflicts and any other necessary validation is done, I would then commit from the root of that working copy.
If you are new to Subversion, I highly recommend reading up on reintegrating branches, what a reflective merge is, and in general how mergeinfo works. The Submerged blog has a lot of great info, as does the svn book.
精彩评论