On Thu, Feb 5, 2009 at 7:06 AM, Jens-Heiner Rechtien
> 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.
I'd just emphasize, be sure you have a 1.5.5 client and try svn up
-rHEAD before running the merge. We were seeing long merges in
Subversion's repository when 1.5 first came out. Our trunk is puny
compared to yours, but it was like 10+ minutes. After the changes
(and doing the svn up) it was back to less than a minute.
It'd be interesting to see if new branches behave better. Ones that
were created after the migration from CVS to SVN.
>>> 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.
I'd have advised you not to do that, but I am inclined to think it
will be OK. You are probably going to need to cleanup the branches
though, else the old mergeinfo is going to make its way back to trunk.
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-05 16:38:11 CET