not sure, all I know is that you need to either mark the branch as
having integrated the change (of the merge from the branch) already
(using the record only cli option, I forget what it's called) or you
have to delete and recreate the branch otherwise reintegrating changes
from trunk will ruin your branch when it tries to merge the changes
from the branch back into the branch
speed wise I find 1.5 merging faster than 1.4 merging as we don't have
to spend ages figuring out what changes to pull in ;-)
Sent from my [rhymes with myPod] ;-)
On 13 Apr 2009, at 12:01, Talden <talden_at_gmail.com> wrote:
> On Mon, Apr 13, 2009 at 9:52 PM, Stephen Connolly
> <stephen.alan.connolly_at_gmail.com> wrote:
>>
>>
>> 2009/4/13 Talden <talden_at_gmail.com>
>>>
>>>> suppose there are 2 developers each working on his own branch.
>>>> From time
>>>> to time a
>>>> feature in a branch is ready to be shared by all other developers.
>>>
>>>> The developer wants to merge the sources from branch to trunk.
>>>> Since he
>>>> is still working
>>>> on the branch he does not want to switch to trunk but simply
>>>> merge from
>>>> his (branch)
>>>> working copy to the trunk. Is it possible?
>>>
>>>> It seems that one has always to switch to trunk before you can
>>>> merge
>>>> from a branch?
>>>
>>> No as far as I am aware Subversion doesn't have this capability.
>>> Several other version control tools do support this (those that I
>>> know
>>> of being distributed version control tools).
>>>
>>> Conceptually, if it were certain that all changes on trunk had
>>> already
>>> been absorbed into the branch (using the same checks that merge
>>> reintegrate uses I expect), Subversion could probably collect the
>>> necessary information from the server to build the diffs necessary
>>> for
>>> a commit (whether it has the necessary out-of-date rules to cause
>>> the
>>> commit to fail if any change to trunk is made during the commit is
>>> something I don't know). I do know this feature somewhat goes
>>> against
>>> the spirit of Subversion (previewing the effect of changes locally
>>> before committing) so I doubt this will ever be supported.
>>
>> Also if you did it this way you'd still face the problem of either
>> marking
>> the branch as having been integrated or deleting the branch and re-
>> creating
>> it... otherwise merge tracking would be fecked
>
> If the diffs can be ascertained, then so should merge-tracking info -
> you'd already have the branch info in the working copy, this kind of
> commit action would need to read and process the trunk info from the
> server and construct the commit (merge-info and all). Obviously this
> is highly unlikely to happen - that's a lot of code for something that
> can be done in another way with existing workflows.
>
> Our working copy (excluding metadata) of 550MB comprises just over
> 2,500 folders and 14,000 files. I can imagine users with larger
> working copies don't enjoy the time Subversion takes in trawling the
> working copy for switch (or any other operation for that matter).
>
> I keep a trunk working copy around for this purpose since a switch on
> a busy branch takes a few minutes... Not that the update and the merge
> aren't painful themselves (mostly because we're a loooong way from the
> server) - Our server is 1.4.x, I shudder to think what the slower
> merging in 1.5+ will be like - is it likely to be slower than using
> the svnmerge.py script we use now?
>
> --
> Talden
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1687809
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-13 13:06:57 CEST