> After scratching my head for a while and reading documentation as best as I > can, I am not able to see a good method for doing the following. > > We use SVN to develop software for an embedded system. Our 'C' code is > developed in parts of the tree that are grouped by project. We have a > seperate tree containing the embedded file system. The file system tree's > binaries and libraries are populated automatically by using SVN externals > from the parts of the tree that we use to develop our code. In other words, > after a major source code change, the programmer commits the library or > executable and by the magic of SVN:externals is appears at the right place on > the file system. A developer only needs to check out his part of the repo, > but can automatically contribute to our final output, the embedded > filesystem. > > For releases we copy our trunk to a tag, rebuild all the code, commit the > libraries and binaries to the tag and then create our file system by pulling > in > the newly comitted binaries/libraries from that tag. That way, a release is > guarenteed to have libraries corrospond to the source code. It works well for > us. > > Problem is, it is not so great for creating a test release. For us to build > our > embedded file system, we *have* to pull its files from SVN and that means > a lot of commits only for testing. Our svn repo is 7GB+ and growing too > fast. > > So here is a simple solution - i thought - for a test release, we extract rev > HEAD from the trunk repository, copy to a temporary SVN repository > created on the fly. This will include all our svn:externals definitions. We > build > the code in the project trees, commit to the temporary repository and build > our file-system from it. If it is a bad test, we just delete the temp > repository. Fix the trunk in the real repo and start again. > > Here is where I need help. I can not find a way of extracting HEAD from a > sub-part of the repo to create a new temp repo. > > 1. svnadmin dump followed by a load would re-create our entire repository, > when I really only need a part. Yes, I could svndumpfilter as a second step > but we are now talking some massive CPU overhead. Secondly it forces us to > build on the same machine (right ?) since you can't dump a URL.
Svnrdump can do this. It's a new util... I'm not sure if it's been released yet, or will only be released with 1.7. > > 2. svnsync can do copies of sub-trees (as of v1.5) but it would copy the > entire > history. > > 3. svn-hot-copy would copy the entire repo and all history. > > 4. svn export followed by svn import would lose all the SVN: externals - our > binaries would get build but never appear in the file-system tree. > > Am I missing a solution ? I'm not understanding why option 4 won't work. Can you not also create a "test" file-system tree using export as well? Sorry I can't be of more help. BOb
