[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion 1.5 about reintegrate and renames

From: rjk1408 <rohanjoseph_at_gmail.com>
Date: Wed, 2 Jul 2008 23:14:33 -0700 (PDT)

Hello Mark,

              You have mentioned that until the feature is fixed, we can use
the 2-URL syntax - but will this fix the problem of merging from branch to
trunk AFTER a rename/move has taken place?

E.g Will the following use case work if I try the merge using the 2-URL

Edit foo.c on branch1
On branch2, rename foo.c to bar.c
Case I: merge branch1 --> branch2
svn merge will skip the file, because it can't find it
Case II: merge branch2 --> branch1
svn merge will delete the 'newer' version of foo.c and add bar.c, which has
the older text


Mark Phippard-3 wrote:
> On Fri, Jun 27, 2008 at 9:57 AM, Tom Widmer <tom.widmer_at_googlemail.com>
> wrote:
>> Baeriswyl Kuno - Extern (IT-BA-MV) wrote:
>>> Hello!
>>> I've installed the collabnet build for RC9 on my windows host. I
>>> followed the instructions in the Subversion Book, though, the first
>>> thing I
>>> tried failed. :
>>> Does anybody know a workaround or best practice for reintegrating
>>> branches
>>> back to the trunk? What's the roadmap to fix this problem?
>> Looks like a bug to me (someone else asked the same question a few hours
>> earlier). I'd suggest you try the developer mailing list.
> We were aware of this before we released. It kind of sits somewhere
> between a bug and just a scenario we need to improve. First off,
> there is nothing magical about svn merge --reintegrate. It is just a
> convenient syntax for how you had to do this kind of merge before 1.5.
> Namely:
> svn merge url://trunk@LAST-SYNC-REV url://branch@HEAD
> Where LAST-SYNC-REV is the last revision from trunk that has been
> synched to the branch. You can still use this syntax with 1.5 and it
> still works. Since --reintegrate is a syntax shortcut and does some
> of this calculation for you, we decided (rightly or wrongly) that it
> should do some checks for possible problem cases and not run the merge
> if it finds any issues. The checks are relatively simple right now
> and what we have to decide is how much it is worth investing in making
> them smarter. In this particular case, the check is just a false
> positive.
> The other thing we can look at, and plan to, is whether renaming
> something really needs to create subtree mergeinfo. In most cases, it
> really doesn't. If no subtree mergeinfo is created, then
> --reintegrate will not have a false positive.
> So until these things are fixed, you either need to use the more
> verbose older 2-URL merge syntax, or you have to use svn propdel to
> remove the subtree mergeinfo that was created when you renamed the
> files.
> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org

View this message in context: http://www.nabble.com/Subversion-1.5-about-reintegrate-and-renames-tp18135802p18252458.html
Sent from the Subversion Users mailing list archive at Nabble.com.
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-07-03 08:14:54 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.