I see occasional complaints about the size of mainline merges to
branches Most people working on branches are only modifying a very
small subset of the files that are in mainline, and certainly not the
entire trunk tree.
You guys should be aware that you can simply branch those files you
want (or those subdir trees you want), and keep the rest at the same
revision as the mainline.
IE you can have
/branches/my-branch-gccdir -copy of only /trunk/gcc
and use svn switch to switch just your gcc subdirectory to this, while
keeping all the other subdirs as mainline.
svn knows how to handle this, and will properly keep everything at the
right revisions.
svnmerge knows how to handle this case, and you will avoid having to
do merges of large dirs like libjava, libstdc++, etc at all.
If you are just writing a new pass, you can probably get away with
branching only a few files, and switching those may be a lot better
strategy than branching the entire trunk tree branch to modify 6 files
in the gcc dir.

Daniel Berlin wrote on 09/27/06 16:37:

If you are just writing a new pass, you can probably get away with
branching only a few files, and switching those may be a lot better
strategy than branching the entire trunk tree branch to modify 6 files
in the gcc dir.

But this means that I'm at the mercy of mainline random breakage, right?
Most of the time I would rather do controlled merges when I know
mainline is in a usable state.

Daniel Berlin wrote on 09/27/06 16:37:

If you are just writing a new pass, you can probably get away with
branching only a few files, and switching those may be a lot better
strategy than branching the entire trunk tree branch to modify 6 files
in the gcc dir.

But this means that I'm at the mercy of mainline random breakage, right?
Most of the time I would rather do controlled merges when I know
mainline is in a usable state.

9/27/06, Diego Novillo <dnovillo (AT) redhat (DOT) comwrote:
Daniel Berlin wrote on 09/27/06 16:37:

If you are just writing a new pass, you can probably get away with
branching only a few files, and switching those may be a lot better
strategy than branching the entire trunk tree branch to modify 6 files
in the gcc dir.

But this means that I'm at the mercy of mainline random breakage, right?
Yes

Most of the time I would rather do controlled merges when I know
mainline is in a usable state.

Some of us like to live on the edge.
Seriously though, it's a tradeoff between how much time you want to
spend on branch maintenance vs how much mainline breakage you are
willing to accept.

I just wanted to throw it out there since some people may not know
it's even possible

9/27/06, Diego Novillo <dnovillo (AT) redhat (DOT) comwrote:
Daniel Berlin wrote on 09/27/06 16:37:

If you are just writing a new pass, you can probably get away with
branching only a few files, and switching those may be a lot better
strategy than branching the entire trunk tree branch to modify 6 files
in the gcc dir.

But this means that I'm at the mercy of mainline random breakage, right?
Yes

Most of the time I would rather do controlled merges when I know
mainline is in a usable state.

Some of us like to live on the edge.
Seriously though, it's a tradeoff between how much time you want to
spend on branch maintenance vs how much mainline breakage you are
willing to accept.

I just wanted to throw it out there since some people may not know
it's even possible

Wednesday 27 September 2006 21:37, Daniel Berlin wrote:
I see occasional complaints about the size of mainline merges to
branches Most people working on branches are only modifying a very
small subset of the files that are in mainline, and certainly not the
entire trunk tree.

I'm kinda surprised this is still a problem.
With svn even big merges should be fairly quick, and if you're only modifying
a small part of the tree then everything else should merge without conflicts.

Am I missing something?

Paul

Wednesday 27 September 2006 21:37, Daniel Berlin wrote:
I see occasional complaints about the size of mainline merges to
branches Most people working on branches are only modifying a very
small subset of the files that are in mainline, and certainly not the
entire trunk tree.

I'm kinda surprised this is still a problem.
With svn even big merges should be fairly quick, and if you're only modifying
a small part of the tree then everything else should merge without conflicts.

Am I missing something?

Paul