Dear SVN users,
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.
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 ?
appreciate your time and comments
Thanks
Gertjan
--
==================================================
Gertjan Hofman
ghofman [at] gmail.com gertjan.hofman [at] honeywell.com
604-982-3574
==================================================
Received on 2011-08-28 23:04:08 CEST