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

Re: [PATCH] HTTPv2 allow client to control transaction name in protocol

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 01 Mar 2011 12:29:16 -0500

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
 * 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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2011-03-01 18:29:53 CET

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.