Martin Hauner wrote:
> Hi,
>
> On 06.04.10 00:01, Stefan Sperling wrote:
>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
>>> [..]
>>> With svn:mergeinfo I have to update after each commit because its on
>>> my root folder and always is out of date on the next commit.
>>
>> The out-of-dateness really comes from the mixed-revision working
>> copy concept, not from mergeinfo.
>>
>> The root of your working copy is not out of date right after
>> the commit. It is at the HEAD revision after commit:
>>
>> $ ls
>> alpha beta epsilon/ gamma/
>> $ svn merge ^/trunk
>> --- Merging r2 through r4 into '.':
>> U alpha
>> --- Recording mergeinfo for merge of r2 through r4 into '.':
>> U .
>> $ svn ci -m merge
>> Sending .
>> Sending alpha
>> Transmitting file data .
>> Committed revision 5.
>> $ svn info . | grep ^Rev
>> Revision: 5
>>
>> Maybe you do not commit the mergeinfo which is set on the root of your
>> working copy? If so, why not?
>
> I always commit merges on the root.
>
> I have tried to create an example, but it works in my test repository. I
> can't reproduce my "at work" behavior.
>
> It still complains that '.' is out of date most os the at work. And I'm
> 100% sure that it started when subversion went merge-tracking.
Subversion has always disallowed commits of propchanges on a directory
that's not fully up to date. Why? For the simple reason that, after the
commit happens, that directory cannot be considered "at the new revision X"
because we never got the changes we were missing from the server.
What happened with merge tracking is that propchanges on directories
suddenly became quite a bit more common. Like ... after every merge.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-04-08 21:35:43 CEST