Mark Phippard wrote:
> On Wed, Feb 4, 2009 at 1:49 PM, Jens-Heiner Rechtien
> <jens-heiner.rechtien_at_sun.com> wrote:
>> 3) More often than not developers have to sync up to a newer milestones
>> before they can finish their work, say in this case milestone
>> DEV300_m41, that is revision 267170.
>> $ cd WC
>> $ svn merge ^trunk_at_267170
> So as an example, how long does a merge like this typically take?
In pathological cases (very old branch) this can take a couple of hours.
It should be noted that the server is located on the other side of the
world, but checkouts etc aren't that slow.
>> 4) RE integrates the feature branch/CWS into the main code line
>> $ svn co ^trunk
>> $ svn merge --reintegrate ^cws/myfeature
>> Actually, it's practically impossible to use --reintegrate due to
>> subtree mergeinfo, so we have to fall back to
> Are you using 1.5.5 client? It is a lot smarter about knowing when
> that subtree mergeinfo is OK? Also, have you considered cleaning up
> this mergeinfo? The 1.5.5 client also no longer creates it when
> copy/rename happens, which should remove all of the incorrect creating
> of subtree mergeinfo. Generally, if using 1.5.5, you should only have
> subtree mergeinfo if you have done subtree merges.
We have upgraded the clients to 1.5.5 just for this reason, server is
still 1.5.4. We deleted all mergeinfo from trunk, not without a certain
uneasy feeling I might add - we think we understand what we are doing
here but .... We have not yet verified if it makes a big difference,
most of the feature branches we integrate still have the old mergeinfo.
This brings me to a nagging question: Was it wrong to remove also the
"root" mergeinfo in trunk? Trunk itself will of course never be merged
back into something else.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-05 13:30:31 CET