Re: (How to ?) copy latest rev of a sub-tree to new repo

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.Archer_at_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
==================================================