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

Re: svn commit: r21540 - in trunk/subversion: libsvn_fs_fs tests/cmdline tests/libsvn_fs

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-09-19 18:20:11 CEST

On Tue, Sep 19, 2006 at 11:04:45AM -0400, David Glasser wrote:
> On 9/19/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> >Oh, okay. But the same applies to all the other contents of the noderev
> >structure :-), doesn't it? I know I'm probably just being picky -
> >I'll make the change myself if you've no objections.
>
> Well, arguably no -- the other parts of the noderev structure need to
> be changed when their actual value changes, whereas this flag needs to
> be cleared whenever you make *any* change to the structure, which
> could happen in many places.
>
> I guess my point is, I'm not sure where I'd put documentation of the
> fact that the flag needs to be cleared on *any* modification, whereas
> this doesn't leave a chance to forget.
>

I've just deleted several paragraphs of analysis disagreeing with you.
You're right, this is the best way to deal with this.

The thing I was getting hung up on is that the noderevs aren't opaque
structures, so this action-at-a-distance is mildly disturbing. But on
the other hand, with one exception, we want to reset that value whenever
we write out the noderev, so I guess it does make sense, even though
we're effectively setting it in places that aren't really applicable,
like rep_write_contents_close(), which deals only with file nodes.

> >Sorry I wasn't clear. We're relying on a certain behaviour from
> >svn_fs_node_created_rev() that's not well documented, specifically that
> >it returns a real revision when called on the root of an unmodified
> >transaction. I was thinking that we should document that in the
> >doc-comments for that function.
>
> Yeah, sounds reasonable.
>

I added a comment in r21555.

Regards,
Malcolm

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 19 18:20:35 2006

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

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