Hello Bob, (havent checked the mailing list - perhaps I will repost there).
Thanks for the response. Option 4 doesnt work, since we build our libraries in certain parts of the SVN tree, then we commit them. Via svn:externals, they then end up into the file-system tree, during a checkout. So we need the initial check-in to get them where we want them. Unless we throw the nifty svn:external feature away and write scripts to copy files around to where we want them. I liked the elegance of the SVN based solution. svnrdump might come some way to providing a solution. I think I have no choice to live with the large CPU overhead: svnrdump --> dumpfilter--> svnadmin load. Every system build would take about 15-20 min or more, but at least it avoids large test commit. Thanks for your time. Gertjan On Mon, Aug 29, 2011 at 6:44 AM, Bob Archer <bob.arc...@amsi.com> wrote: > > 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 > > > -- ================================================== Gertjan Hofman ghofman [at] gmail.com gertjan.hofman [at] honeywell.com 604-982-3574 ==================================================
