Mark Phippard wrote:
> On Thu, Feb 5, 2009 at 7:06 AM, Jens-Heiner Rechtien
> <Jens-Heiner.Rechtien_at_sun.com> wrote:
>> 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.
OK the SVN 1.5.5 client and an update to the branch HEAD it is. That's
exactly what we recommend our developers and what we use in OOo RE.
>
> It'd be interesting to see if new branches behave better. Ones that
> were created after the migration from CVS to SVN.
Oh, we didn't take over any branches and tags from CVS. Just plain trunk
history of active files (and no history for binaries at all). Resulted
in a nice litte repository of about 6 GByte size. With all the ~500
living branches the repository size would have been ~90 GBytes. With all
5000 historical branches ... well ...
All branches have been created by SVN clients 1.5.2 or newer.
>
>
>>>> 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.
Yes, currently we remove the all the mergeinfo on trunk which comes in
due to reintegration. This way we hope to keep trunk clean.
Heiner
--
Jens-Heiner Rechtien
rechtien_at_sun.com
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1108232
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-05 17:54:23 CET