Re: Log message templates revisited.

Greg Hudson wrote:
> On Tue, 2005-11-08 at 22:41 -0800, Jim Blandy wrote:
>> Let's presume that propget_walking_upward could be made to work
>> off-line. (I don't quite know how to do that, but let's just keep the
>> issues separate.) Are you sure its semantics aren't the ones you
>> actually want?
>
> They sound like fine semantics. :) I'm just not sure how to make it
> work offline either.

Can't you just work upward in the WC directories until you don't
find a .svn directory or find one with different repo info?

For example, let's say I have the following WC directory structure:

     mybigapp/
         module1/
             source/
                 file1.c
         module2/
             source/
                 file2.c
         source/
             file3.c

Now, "mybigapp" references module1 and module2 via svn:externals, so
each of those modules and mybigapp have a different repo UUID. If I
commit file1.c, then the WC code can look upwards until it reaches
the mybigapp directory, at which point it will see a different UUID
and stop looking. The issue with this design is that you need to
define the (inherited) property at the top level of the directories
you normally checkout for the off-line lookup to work...

<hand-waving>

One possible solution to this is to cache the iprops in each
directory. When doing a checkout or update, the client could
do the on-line iprop search to populate the dir-props file. You'd
need to have an extra flag that specifies whether a property is
inherited/cached or set for the current directory. Inherited/cached
properties would always be updated, while non-inherited properties
would only be updated as needed (as is now the case).

</hand-waving>

The caching implementation does have a potential side-effect.
Consider the directory structure above: I change the svn:l-m-t
property on module1, but then only commit file1.c in the source
sub-directory. Do we use the new svn:l-m-t value that has not
yet been committed, or do we stick with our cached value?

If we use the new-but-uncommitted value, then we still need to
walk the WC directories to find the most authoritative value of
the property.

If we use the cached value, then the only change we need to make
in the client code is for checkout and update (all of the other
consumers will get the props from the same place).

<more-hand-waving>

Conceivably, all of this could be put in the FS code - when a
client asks for the directory properties, the server responds
with the directory and inherited properties in the one call.
This would save a second round-trip with the server, works with
older clients, and is probably simpler to implement.

The server-side implementation does assume that we want to use
the cached dirprop values from the commit directory...

</more-hand-waving>

Thoughts?

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org