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

Re: mergeinfo not inherrited when I thought it should

From: Pieter-Jan Busschaert <pieterjan.busschaert_at_gmail.com>
Date: Tue, 2 Nov 2010 11:29:12 +0100

Hello,

Here is some more information:

>> Inside branch1/subfolder, we do a merge from trunk/subfolder.
>
> Do you mean trunk/project/subfolder here?

yes

> Anyway, branch1/subfolder does not have any mergeinfo,
> since the previous merge was done on branch1. So Subversion
> does not know that you have already merged the changes to line 1.

Correct, but isn't SVN supposed to crawl up the tree to find
mergeinfo? I thought this was the most simple usecase of inherited
mergeinfo, which is described in various places, for instance here:
http://help.collab.net/index.jsp?topic=/faq/mergeinfo.html

> Merges from trunk to branch and vice-versa should always be done
> from the root of the project (in your case branches/project/branch1)

I can not believe this is true. I can not control the other users and
I have had reports of similar issues from a few different users here,
so it seems a real use case.

> I don't think so, as I think Subversion did the correct thing, given the information it has.

Well, I still think it did not do the correct thing, as it had more
info available than it actually used.

> However, I recommend you to push for an upgrade of SVN, as I remember 1.5 was not particularly good with merging.

I have just tested with 1.6.13 on a test pc and it behaves exactly the same.

By reading the details of inherited mergeinfo in the collabnet FAQ,
maybe the bug is because mergeinfo is not up to date in the working
copy and SVN uses that instead of contacting the repository. If this
is the case, I would expect SVN to give me a "please update" warning
when I do the merge command.

Kind regards,

Pieter-Jan
Received on 2010-11-02 11:30:10 CET

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.