> 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
Received on 2011-08-29 15:45:49 CEST