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

Re: 2 repositories, how to branch into one, work there, then merge back?

From: Ryan Schmidt <subversion-2009b_at_ryandesign.com>
Date: Sun, 23 Aug 2009 17:54:55 -0500

On Aug 23, 2009, at 17:36, John Owens wrote:

> I work on a project that's stored on Google Code via svn.
> I'd like to do a big change and store that in a local
> svn server as I develop it, and then merge the whole big
> change back onto Google Code when I'm done (with none of
> the intermediate changes visible on Google Code). Didn't
> find anything that dealt with the 2-server problem in the
> FAQ and the book; sorry if I missed it.

That's really not a workflow that's going to be possible with

You should request commit access to the Google Code project, and
create a branch there, which can then be merged back to the trunk
when it's done.

> I am guessing this is the sequence; can I get some feedback?
> 1) On my local repository, set up a svn externals for the
> Google Code repository and check it out. (Is this right?
> If I check in changes, will they go to Google Code or to
> my local repository? I want the latter.)

Changes to the contents of an external will go to the place the
external points to -- in this case, to the Google Code repository. So
that's not what you want.

> 2) Make changes, checking into my local repository.
> 3) Keep up to date with changes on the Google Code respository
> with a simple svn update.
> 4) When I'm done, run a svn merge from my local repository
> with an argument of the Google Code repository to push
> the changes back to Google Code.
> Those are I think the steps I want, but I'm unclear if I am
> doing the right mechanics to make 'em work.
> Also, my local repository is still running 1.4.2; should I be
> pushing the admins to upgrade it >= 1.5 before I start this
> process? (I know externals got better with 1.5.)

Relative externals are possible with 1.5 but externals are probably
not relevant to what you want to accomplish.

If you cannot gain commit access to the main repository, you could
handle it like a vendor branch. There is a chapter in the book on
vendor branches. Basically you import the entire existing code into
your repository at /vendor/PROJECT/current (this is akin to trunk,
except you never make your own changes here or anywhere else inside /
vendor; this is meant to be an exact unmodified copy of the vendor
software). Then you copy it to /vendor/PROJECT/VERSION (this is akin
to a tag). Then you copy it to /SOMEWHERE/PROJECT. Then you start
making changes in /SOMEWHERE/PROJECT. Once you're done, you can ask
your repository for a diff between /vendor/PROJECT/VERSION and /
SOMEWHERE/PROJECT and send that as a patch to the owners of the main


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-24 00:55:53 CEST

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.