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

Re: best practices to keep a local branch up2date

From: eg <egoots_at_gmail.com>
Date: Tue, 12 Feb 2008 11:58:37 -0800

Dieter Oberkofler wrote:
> Up until now I have been mostly using a local trunk but I'm now starting to
> more and more use local branches when making some more complex changes on
> our project and was wondering what the most appropriate way would be to keep
> my branch up2date with the changes in the trunk.
> I've read the documentation and am aware that this can be done by "merging"
> the changes in the trunk into my branch but was wondering:
> 1) I feel that being as close as possible to the trunk (or more generally
> the source of my branch) is generally a good idea. Is this reasonable?

Sure. I prefer to minimize merging if I can.

> 2) Should the merging best done in the branch on the server and then update
> the local one or immediately on the local one and then commit the changes?

Not quite sure I follow given your use of terminology.

What do you mean by local versus server? Are you talking about different
checked out working copies?

Or...
Are you asking about whether to commit changes to trunk and merge to the
branch... versus committing changes to the branch and merging to the trunk?

> 3) It is a little complicated to keep track of what has been already merged
> or what needs to be merged. What is the best technique to proceed here and
> what happens if I merge twice the same changes?

I would highly recommend using svnmerge.py which will address #3.

See the following webpage for usage notes including certain workflows:
http://www.orcaware.com/svn/wiki/Svnmerge.py

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-12 20:59:06 CET

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.