[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Update two SVN repositories

From: Ryan Schmidt <subversion-2007b_at_ryandesign.com>
Date: 2007-04-25 23:04:16 CEST

On Apr 25, 2007, at 11:31, dieter oberkofler wrote:

>>> What would be the best practice to solve the following situation:
>>> I use a SVN repository from a vendor that is regularly updated on
>>> the
>>> vendors SVN side.
>>> I have a local working copy of the vendors repository with local
>>> modifications.
>>> I would like to create a local SVN repository on my site and keep my
>>> working copy in sync with the vendors and my local SVN repository.
>>
>> You should read the section of the book on Vendor Branches. You'll
>> basically
>> ignore the fact that the vendor's code is available via Subversion
>> at all,
>> and just periodically import new versions of their code into your
>> repository
>> using a script called svn_load_dirs.pl. You can make a copy of
>> their code to
>> anywhere else in your repository and start making changes. When
>> you want to
>> update your code with new code of theirs, you can merge from the
>> imported
>> version of their code to yours.
>>
>> http://svnbook.red-bean.com/nightly/en/svn.advanced.vendorbr.html
>
> Thank you for your feedback. I've read the article and have
> understood the
> concept.
> What remains, is one question: Because I must download the vendors
> source
> (several 100MB in my case) directly from a SVN repository, I would
> need to
> always export the complete repository over the Internet just to
> completely
> reimport all of it in a local SVN repository even if only a single
> character
> has changed. If there really now way to somehow sync two separate SVN
> repositories?

There are other ways to sync repositories, but I don't think they're
well-suited to your scenario.

There's svnsync, but it can only sync an entire repository (you may
only want one project out of their repository, or one branch of it),
and besides the copy svnsync makes is meant to be read-only, but you
want to modify it.

There's SVK, which is based on Subversion, but I think this is more
designed for the case where you were doing some offline work in your
copied repository and then would send these changes back up to their
repository, but it doesn't sound like that's what you want either.
But you could look into SVK and see if it sounds like it would be
useful to you. http://svk.bestpractical.com/

I would stick with the Vendor Branch strategy I described. Note that
you do not need to export over the Internet. You can just as easily
export from a local working copy. So my recommendation would be to
have a local working copy of their project. When you want to bring it
into your repository, you would:

- "svn update" that working copy (which will only pull the changes
over the network, not the entire hundreds of MB), then
- "svn export" it to a temporary location on disk (which is a local
operation and will not use the network at all), then
- use "svn_load_dirs.pl" to load it into your repository, and finally
- delete the temporary export you made.

Note that svn_load_dirs.pl will check out a complete working copy
from *your* Subversion server in order to do the import. If your
Subversion server is local to you, or if it's on a fast network
connection and you don't care about bandwidth, then this is no
problem. If the bandwidth is a problem, though, then I believe you
can configure svn_load_dirs.pl to use an existing local working copy
from your repository instead. I haven't had to look into that before,
though.

-- 
To reply to the mailing list, please use your mailer's Reply To All  
function
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Apr 25 23:04:52 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.