> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: donderdag 8 april 2010 22:41
> To: C. Michael Pilato
> Cc: dev_at_subversion.apache.org
> Subject: Re: Properties (was Re: Subversion Vision and Roadmap
> Proposal)
>
> On Thu, Apr 8, 2010 at 15:35, C. Michael Pilato <cmpilato_at_collab.net>
> wrote:
> > 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.
>
> If there are no propchanges on the directory in the interim, then why
> not allow the commit?
>
> IOW, did we disallow because we were lazy, or is there a fundamental
> problem with allowing the commit to proceed?
We can only do this if there are no property changes on the directory *and*
when there are no children added or removed from the directory.
(This is not necessary an issue on committing, but when we upgrade the
revision number of the directory, without updating the list of children this
list of children is out of date in a way that can't be fixed by updating).
Bert
Received on 2010-04-11 18:23:46 CEST