On 03/01/2011 11:50 AM, Philip Martin wrote: > "C. Michael Pilato" <cmpil...@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 * set. 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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
