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=1687670
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-04-13 13:02:03 CEST