On 03/01/2011 11:50 AM, Philip Martin wrote:
> "C. Michael Pilato" <cmpilato_at_collab.net> writes:
>> On 03/01/2011 10:09 AM, Philip Martin wrote:
>>> Index: subversion/mod_dav_svn/dav_svn.h
>>> --- subversion/mod_dav_svn/dav_svn.h (revision 1075718)
>>> +++ subversion/mod_dav_svn/dav_svn.h (working copy)
>>> @@ -52,6 +52,9 @@
>>> /* a pool-key for the shared dav_svn_root used by autoversioning */
>>> #define DAV_SVN__AUTOVERSIONING_ACTIVITY "svn-autoversioning-activity"
>>> +/* used to distinguish client supplied TXN-NAME from FS supplied, this
>>> + is a string that is NEVER the start of an FS transaction name */
>>> +#define DAV_SVN__VISIBLE_TXN_PREFIX "$"
>> Whoops! Technically, mod_dav_svn hasn't access to the knowledge required to
>> make this assertion. Who says a transaction's name can't start with a
>> dollar sign?
> I suppose I should make the comment more accurate. The prefix
> determines whether the visible:internal mapping will apply. If a
> internal transaction's name starts with the prefix then an identity
> mapping will get applied. That still works but the overhead of going
> through the activity database makes it marginally less efficient.
My point was merely that we don't document anywhere the limitations of a
Subversion filesystem transaction's naming scheme, therefore it is not
possible for a dependent library to declare that any given string falls
outside that naming scheme.
BUT. I was wrong. I just found in svn_fs.h the following:
* Transaction names are guaranteed to contain only letters (upper-
* and lower-case), digits, `-', and `.', from the ASCII character
Given this, it's perfectly fine for mod_dav_svn to make such declarations.
> There is a demand for WANdisco's replicator. It may be the only product
> at the moment but it's possible that somebody will write an open source
> product that also does multiplexing and/or replay. They will then face
> the same problem that WANdisco does now.
I think you've missed the point, Philip. This isn't about WANdisco or its
(arguably rather useful) product. It's about Subversion. It's about
reversing steps we intentionally took to de-obfuscate the way that
repository transactions are referred to by the Subversion client. It's
about taking a clean protocol definition:
".../!svn/txn/TXN-NAME/" and ".../!svn/txr/TXN-NAME/...", where TXN-NAME
is a Subversion filesystem transaction name.
and muddying it up:
".../!svn/txn/SOME-STRING/" and ".../!svn/txr/SOME-STRING/...", where
SOME-STRING is either a magic token (identified by a prefix consisting
of characters not legal in a Subversion filesystem transaction name)
which the server knows how to map to a transaction name, or is just a
transaction name itself.
Now, maybe we were short-sighted to take these steps in the first place.
Maybe it's better if the client always refers to transactions through some
layer of indirection such as the activity database subsystem. I don't know.
I just don't want to grumble every time I think about the HTTPv2 spec.
Just a thought: Have you considered expanding the scope of the private
resource space rather than using the magic prefix hack? You could add
".../!svn/vtxn/UUID" and ".../!svn/vtxr/UUID/..." to be alternate ways to
address transactions and transaction roots (the "v" there being a shortcut
for "virtual"). This is *effectively* the same approach as yours -- there's
a different prefix here. But the prefix is a clearly defined piece of the
protocol, not just some magic bit buried in mod_dav_svn's codebase.
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-03-01 18:29:53 CET