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

[John Owens <jo...@yahoo.com>]

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.

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.)

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.)

Thanks -

JDO

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2386591

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[James Mansion <ja...@mansionfamily.plus.com>]

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
>   
You might find some support from this in bzr - try asking there.  (Tho on my
PC, the integration doesn't work properly and I disable it).

James

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2389935

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Ulrich Eckhardt <ec...@satorlaser.com>]

On Monday 24 August 2009, 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).

Why shouldn't the intermediate changes be visible? I find smaller steps easier 
to understand and someone suggesting a giant, monolithic patch will have a 
hard time getting it accepted upstream.

> 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.)

The changes will be committed externally, so this doesn't work.

Options:

0. Get access upstream. This is actually the preferred way IMHO, because it 
integrates with upstream's development. Changes are seen earlier and, if 
necessary, vetoed earlier, too.

1. Check out svn_load_dirs. This script takes a sourcetree and imports/updates 
it into a repository. This is used for tracking vendor branches, which is 
effectively what you want.

2. http://bitbucket.org/nikhilm/cq/src/tip/README
This is pretty similar to option 1, but it uses a different repository for
the local changes. The main advantage is the offline work, not so much the 
independence from the upstream repository. I just added this here for 
completeness, because I'm not 100% sure what your goals are.

Uli

-- 
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/

Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932

**************************************************************************************
Sator Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
           Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2386668

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Ryan Schmidt <su...@ryandesign.com>]

On Aug 23, 2009, at 18:03, John Owens wrote:

> Ryan Schmidt writes:
>
>> 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.
>
> Oh, that'll work fine, I can totally do that. Duh. Didn't know
> Google Code could support that. Thanks Ryan.

Good. :) It will of course be up to the owners of the Google Code  
project in question whether they give you commit access or not. But  
doing your work there would be much better from a collaboration and  
communication standpoint. Google Code is for open-source projects,  
meaning they are developed in the open, so it's better that you don't  
hide your work away in some separate repository. Do it in the main  
repository, and commit to your branch early and often, so that other  
project members see your changes and can provide feedback on them.  
It's always good to have more eyes on your code, looking at it in  
different ways than you might. They might point out issues you never  
thought of. And it's much easier for someone to review small  
individual changes as you're developing them than a single huge  
change once you're done.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2386596

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[John Owens <jo...@yahoo.com>]

Ryan Schmidt <subversion-2009b <at> ryandesign.com> writes:

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

Oh, that'll work fine, I can totally do that. Duh. Didn't know
Google Code could support that. Thanks Ryan.

JDO

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2386595

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].

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

[Ryan Schmidt <su...@ryandesign.com>]

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  
Subversion.

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  
repository.

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2386593

To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].