You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by solo turn <so...@gmail.com> on 2005/08/22 12:56:59 UTC
Re: Older versions through http-repository browsing
hi,
why is it not possible to extend webdav or deltav standard to also
have a means of retrieving a version/revision of a resource like:
http://svn.collab.net/repos/svn/trunk/README?rev=1000
which would allow normal apache access control on the url?
is there any disadvantage in this approach i am not able to see?
-solo
On 3/4/05, Greg Stein <gs...@lyra.org> wrote:
> On Fri, Mar 04, 2005 at 10:20:08AM -0600, Ben Collins-Sussman wrote:
> >...
> > Matthias: you keep saying that the ability to look at an arbitrary
> > repository object in a browser is some sort of "killer" or "critical"
> > feature of Subversion. Let me eradicate that idea from your mind:
> > this is *not* a core feature of Subversion. It's an accidental
> > artifact of the fact that one of our servers just happens to use HTTP,
> > and that HTTP GET just _happens_ to grab the latest version of the
> > file. It's not a designed feature, nor is it a planned one. We don't
> > go around bragging about it or listing it in any whitepapers. Remember
> > that half of all svn installations don't even use apache as their
> > server!
>
> What are you talking about, Ben? It *is* a designed and planned feature of
> Subversion. Five years ago, I said that we ought to use HTTP *precisely*
> so that we can have this feature. You and Karl blustered about wanting a
> custom, binary protocol but didn't mind if I wrote up the DAV stuff. Once
> you (Ben) mounted an SVN repository on your Windows box, you were sold.
>
> So: the "latest version" reachable at a URI is very much a part of the
> design. Maybe not a core conceptual part of Subversion as a version
> control system, but very much a central aspect of (one of) its network
> communication models.
>
>
> All that said, the question here is about the private space. We have
> always called it private in case we needed to monkey it around in the
> future for better WebDAV compatibility. The "!svn" part is customizable by
> the server administrator on the off-chance somebody actually needs to a
> file or directory named "!svn" into their repository (or they just feel
> like being contrary).
>
> But, as we discussed in IM, there is a middle ground here. While we still
> don't want to expose "!svn/bc/NNNN/" in any way (in case we need to change
> it later), we *can* expose "!svn/rev/NNNN/" and just define that tree as a
> revision tree for *servers* to use.
>
> Note that I say servers. Clients cannot assume that path construction. Any
> given server might change the "!svn" portion.
>
> But for rewrite tools, CGIs, etc, it is quite possible to build a tool
> around ".../rev/NNNN/". Since the CGI or other tool is installed by the
> server admin, who also controls the special URI prefix, then they can all
> be coordinated.
>
> The changes to mod_dav_svn should be minimal. In repos.c, there is a
> special_subdirs[] array. Copy/paste the { "bc", ... } section and rewrite
> it to "rev". That should be it. If we ever need to change the "bc" stuff,
> then it will get more complicated, but until then, the two are precisely
> the same.
>
> Cheers,
> -g
>
> --
> Greg Stein, http://www.lyra.org/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by kf...@collab.net.
Duh -- sorry, of course that was a braino, I didn't really mean that
svnserve would start supporting HTTP. All that's needed is
mod_dav_svn support below. Sorry for the confusion.
-K
kfogel@collab.net writes:
> Why don't we just implement server-side support for the trailing
> "@NNN" syntax already supported by the client? This would be in both
> mod_dav_svn and svnserve. We already have an elegant escaping
> mechanism for it, too, for paths that contain @-signs.
>
> All of this is already documented for the client, and (obviously) it's
> best if the client-side syntax is the same as the browser syntax. It
> shouldn't be hard to implement in the servers.
>
> Am I missing something, or would this solve our problem totally?
>
> By the way, this thread is very old and large, more than 50 messages.
> In case anyone wants to review the past conversation (as I just did),
> here is its URL:
>
> http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=298934
>
> -Karl
>
> --
> www.collab.net <> CollabNet | Distributed Development On Demand
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
>Nonono. Please *do not* do this to public URL namespace.
>
*shudder*
Yes, what a horrible idea that is.
>I much prefer the !svn/rev/NNNNN/path syntax, because besides not
>destroying the integrity of our existing URL namespace (...), it allows for relative URLs in HTML documents served
>directory from mod_dav_svn to continue to work.
>
+1.
And -1 on the other proposal.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by kf...@collab.net.
kfogel@collab.net writes:
> I do think browsers and clients need to support the same syntax. It
> would just be ridiculous for people not to be able to cut-and-paste
> between the two contexts.
Well, I guess if the server supports it, the client automatically does
(esp. if the server handles the escape-syntax itself anyway).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Ben Collins-Sussman <su...@collab.net>.
C. Michael Pilato wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
>
>
>>The problem we had before was people becoming familiar
>>"!svn/bc/REV/path" after using it in a web browser for a while... and
>>then they'd go and use the same URL with 'svn cat' and get errors.
>>Then we'd hear complaints.
>>
>>Should we just ignore this problem? Is it a non-problem? Or is
>>there just no acceptable solution to it?
>
>
> What problem? ;-)
>
Oy
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> The problem we had before was people becoming familiar
> "!svn/bc/REV/path" after using it in a web browser for a while... and
> then they'd go and use the same URL with 'svn cat' and get errors.
> Then we'd hear complaints.
>
> Should we just ignore this problem? Is it a non-problem? Or is
> there just no acceptable solution to it?
What problem? ;-)
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Ben Collins-Sussman <su...@collab.net>.
> I'd much rather just let 'svn info' reveal the "!svn/bc/" URL for a
> resource (especially now that it accepts public @-syntax URLs as
> input) and let people copy *that* and paste it into their browser than
> to have our server (which, by the way, has an open network protocol
> that anyone can use, as has been demonstrated by the likes of JavaSVN)
> complexify its very simple public URL schema and require all clients
> of mod_dav_svn to know about those intricacies.
>
The problem we had before was people becoming familiar
"!svn/bc/REV/path" after using it in a web browser for a while... and
then they'd go and use the same URL with 'svn cat' and get errors. Then
we'd hear complaints.
Should we just ignore this problem? Is it a non-problem? Or is there
just no acceptable solution to it?
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej <br...@xbc.nu> writes:
> kfogel@collab.net wrote:
>
> >"C. Michael Pilato" <cm...@collab.net> writes:
> >
> >>Nonono. Please *do not* do this to public URL namespace. It's one
> >>thing to bind revision numbers to URLs in our command-line client
> >>syntax for the sake of UI and path/rev association simplicity (and
> >>yes, remember that this URL@REV syntax is not Subversion-wide -- it's
> >>only in our one little commandline client). But this change has no
> >>place trickling into mod_dav_svn.
> >>
> >
> >Uh, why not make any such syntax Subversion-wide? I mean, this
> >is... Subversion, after all :-).
> >
> Hah. So why don't we support bugtraq properties in the command-line
> client? TSVN does, and it's Subversion, after all ... :)
Besides that somewhat irrelevant bit of trivia (sorry, Brane), it's
entirely unnecessary for clients with UIs more conducive to visual
association between a URL (or path) and a revision number. Again, the
reason that we have an @-syntax *at all* is because command-line
interfaces have inherent limitations in terms of item associations.
It's a one-dimension layout, where the ideal situation for mapping
sets of URLs to sets of revisions is (obviously) a two-dimensional
grid.
I just don't think this is a wise instance of trying to code for the
lowest common denominator. Subversion is a version control system
with multiple RA interfaces. That one of them happens to work okey
dokey sorta kinda in a web browser is a major benefit to users of that
particular RA layer. But with the exception of the
'!svn-in-the-root-dir' limitation noted by Brane, we already have a
syntax, albeit "private", for accessing every version of every
versioned thing.
I'd much rather just let 'svn info' reveal the "!svn/bc/" URL for a
resource (especially now that it accepts public @-syntax URLs as
input) and let people copy *that* and paste it into their browser than
to have our server (which, by the way, has an open network protocol
that anyone can use, as has been demonstrated by the likes of JavaSVN)
complexify its very simple public URL schema and require all clients
of mod_dav_svn to know about those intricacies.
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Branko Čibej <br...@xbc.nu>.
kfogel@collab.net wrote:
>"C. Michael Pilato" <cm...@collab.net> writes:
>
>
>>Nonono. Please *do not* do this to public URL namespace. It's one
>>thing to bind revision numbers to URLs in our command-line client
>>syntax for the sake of UI and path/rev association simplicity (and
>>yes, remember that this URL@REV syntax is not Subversion-wide -- it's
>>only in our one little commandline client). But this change has no
>>place trickling into mod_dav_svn.
>>
>>
>
>Uh, why not make any such syntax Subversion-wide? I mean, this
>is... Subversion, after all :-).
>
>
Hah. So why don't we support bugtraq properties in the command-line
client? TSVN does, and it's Subversion, after all ... :)
>If we're going to go with a prefix syntax, in order to support
>relative URLs, what is the quoting mechanism? Is it to specify HEAD
>or a revnum in a prior prefix, like this?:
>
> http://.../!svn/HEAD/!svn/4500/index.html
> http://.../!svn/1729/!svn/4500/index.html
>
>This would access either HEAD or r1729 of a file whose literal path is
>"/!svn/4500/index.html".
>
>
If you have a directory called !svn at the root of your repository,
browsing will most likely not work. This has been a limitation for a
long, long time.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by kf...@collab.net.
"C. Michael Pilato" <cm...@collab.net> writes:
> Nonono. Please *do not* do this to public URL namespace. It's one
> thing to bind revision numbers to URLs in our command-line client
> syntax for the sake of UI and path/rev association simplicity (and
> yes, remember that this URL@REV syntax is not Subversion-wide -- it's
> only in our one little commandline client). But this change has no
> place trickling into mod_dav_svn.
Uh, why not make any such syntax Subversion-wide? I mean, this
is... Subversion, after all :-).
> I much prefer the !svn/rev/NNNNN/path syntax, because besides not
> destroying the integrity of our existing URL namespace (what happens
> if you have a file with '@[0-9]+' at the end of it under version
> control?),
Like I said, the same quoting mechanism would work as we currently use
for the client: tack on an empty "@", which means "@HEAD", or if you
want a particular revision, tack on "@NNN".
The quoting is a *solved* problem. That remains true if we start
using this syntax in more places.
> it allows for relative URLs in HTML documents served
> directory from mod_dav_svn to continue to work. An index.html with a
> URL of http://.../!svn/4500/index.html can reference "./logo.png" and
> the browser will know to use http://.../!svn/4500/logo.png to fetch
> that image.
The breaking of relative URLs is a valid objection, yeah. Thanks, I'd
forgotten about that one.
I do think browsers and clients need to support the same syntax. It
would just be ridiculous for people not to be able to cut-and-paste
between the two contexts.
This would imply that servers too should support the trailing-"@"
syntax, but that there should also be *another* syntax available to
both clients and servers (which is yucky, I freely confess, but maybe
not as yucky as not having the feature).
If we're going to go with a prefix syntax, in order to support
relative URLs, what is the quoting mechanism? Is it to specify HEAD
or a revnum in a prior prefix, like this?:
http://.../!svn/HEAD/!svn/4500/index.html
http://.../!svn/1729/!svn/4500/index.html
This would access either HEAD or r1729 of a file whose literal path is
"/!svn/4500/index.html".
Do we want "!svn", or maybe "!rev" to be clearer? Or "@rev"??
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by "C. Michael Pilato" <cm...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> On Aug 23, 2005, at 2:30 PM, kfogel@collab.net wrote:
> >
> > Am I missing something, or would this solve our problem totally?
>
>
> When folks pointed out that mod_dav_svn already has a 'private'
> syntax for version-urls (!svn/bc/NNNNN/path), Greg Stein's reaction
> was, "hey, let's just make a public variant of that syntax -- !svn/
> rev/NNNNN/path -- it's a one line code change. And we can promise to
> never change it."
>
> But I like Karl's "path@REV" syntax proposal better, because
>
> 1. it's easier to remember.
>
> 2. it matches the existing svn commandline syntax.
>
>
> The great thing about #2 is that it prevents confusion. In earlier
> threads, there was confusion about people typing "http://host/repos/!
> svn/bc/NNNNN/path" in their web browser, and then going to the prompt
> and feeding the same URL to 'svn cat'. We want to avoid such mix-
> ups. Having identical syntax avoids the confusion.
Nonono. Please *do not* do this to public URL namespace. It's one
thing to bind revision numbers to URLs in our command-line client
syntax for the sake of UI and path/rev association simplicity (and
yes, remember that this URL@REV syntax is not Subversion-wide -- it's
only in our one little commandline client). But this change has no
place trickling into mod_dav_svn.
I much prefer the !svn/rev/NNNNN/path syntax, because besides not
destroying the integrity of our existing URL namespace (what happens
if you have a file with '@[0-9]+' at the end of it under version
control?), it allows for relative URLs in HTML documents served
directory from mod_dav_svn to continue to work. An index.html with a
URL of http://.../!svn/4500/index.html can reference "./logo.png" and
the browser will know to use http://.../!svn/4500/logo.png to fetch
that image.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Ben Collins-Sussman <su...@collab.net>.
On Aug 23, 2005, at 2:30 PM, kfogel@collab.net wrote:
>
> Am I missing something, or would this solve our problem totally?
When folks pointed out that mod_dav_svn already has a 'private'
syntax for version-urls (!svn/bc/NNNNN/path), Greg Stein's reaction
was, "hey, let's just make a public variant of that syntax -- !svn/
rev/NNNNN/path -- it's a one line code change. And we can promise to
never change it."
But I like Karl's "path@REV" syntax proposal better, because
1. it's easier to remember.
2. it matches the existing svn commandline syntax.
The great thing about #2 is that it prevents confusion. In earlier
threads, there was confusion about people typing "http://host/repos/!
svn/bc/NNNNN/path" in their web browser, and then going to the prompt
and feeding the same URL to 'svn cat'. We want to avoid such mix-
ups. Having identical syntax avoids the confusion.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by kf...@collab.net.
Branko Čibej <br...@xbc.nu> writes:
> solo turn wrote:
>
> >sorry for beeing unclear before. i did want to write that the standard
> >should include a unique method of retrieving versions, and not leave
> >it to the server. and i'm still wondering what drawbacks this could
> >have - personally i do not see any for such a simple and natural
> >problem. for me its something like "leave the url syntax to be defined
> >by the server" for http servers.
>
> Well, I can only suggest that you start the process for revising the
> current WebDAV/DeltaV RFC.
Why don't we just implement server-side support for the trailing
"@NNN" syntax already supported by the client? This would be in both
mod_dav_svn and svnserve. We already have an elegant escaping
mechanism for it, too, for paths that contain @-signs.
All of this is already documented for the client, and (obviously) it's
best if the client-side syntax is the same as the browser syntax. It
shouldn't be hard to implement in the servers.
Am I missing something, or would this solve our problem totally?
By the way, this thread is very old and large, more than 50 messages.
In case anyone wants to review the past conversation (as I just did),
here is its URL:
http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=298934
-Karl
--
www.collab.net <> CollabNet | Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Julian Reschke <ju...@gmx.de>.
Branko Čibej wrote:
> solo turn wrote:
>
>> sorry for beeing unclear before. i did want to write that the standard
>> should include a unique method of retrieving versions, and not leave
>> it to the server. and i'm still wondering what drawbacks this could
>> have - personally i do not see any for such a simple and natural
>> problem. for me its something like "leave the url syntax to be defined
>> by the server" for http servers.
>>
>>
> Well, I can only suggest that you start the process for revising the
> current WebDAV/DeltaV RFC.
I'd be surprised if you can get three implementors of different DeltaV
servers into one room and get them to agree on a single format. That
being said, I'm still not sure what the problem is.
If the client is for a single server, just rely on the format it's
using. RFC3253 mandates that a version URI is immutable, that is it'll
never change.
On the other hand, if the client is supposed to work with multiple
servers, PROPFINDing the version URIs really is trivial.
Best regards, Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Branko Čibej <br...@xbc.nu>.
solo turn wrote:
>sorry for beeing unclear before. i did want to write that the standard
>should include a unique method of retrieving versions, and not leave
>it to the server. and i'm still wondering what drawbacks this could
>have - personally i do not see any for such a simple and natural
>problem. for me its something like "leave the url syntax to be defined
>by the server" for http servers.
>
>
Well, I can only suggest that you start the process for revising the
current WebDAV/DeltaV RFC.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by solo turn <so...@gmail.com>.
sorry for beeing unclear before. i did want to write that the standard
should include a unique method of retrieving versions, and not leave
it to the server. and i'm still wondering what drawbacks this could
have - personally i do not see any for such a simple and natural
problem. for me its something like "leave the url syntax to be defined
by the server" for http servers.
-solo.
On 8/22/05, Phillip Susi <ps...@cfl.rr.com> wrote:
> I find that you can access older revisions via web browser by using URLs
> like this:
>
> https://server/svn/!svn/bc/123 where 123 is the revision number you seek.
>
> I'm not sure why this isn't documented in the SVN book. According to
> the DelvtaV standard, the URL syntax used to differentiate between
> versions is left up to the server, and the client needs to use special
> requests to ask the server what URL to use to access specific versions.
> I looked at apache's access log though and found that svn was using
> URLs like the above, and gave it a try and it worked.
>
>
>
> Michael Sinz wrote:
> > solo turn wrote:
> >
> >>hi,
> >>
> >>why is it not possible to extend webdav or deltav standard to also
> >>have a means of retrieving a version/revision of a resource like:
> >>http://svn.collab.net/repos/svn/trunk/README?rev=1000
> >>which would allow normal apache access control on the url?
> >
> >
> > Actually, using the rewrite trick that I have in the Insurrection tools,
> > this sort of works. That is, the mod_authz_svn does all of the URL
> > access controls because the access controls are handled before the
> > .htaccess rewrite rules run.
> >
> >
> >>is there any disadvantage in this approach i am not able to see?
> >
> >
> > Other than making mod_dav_svn be more than what it is (and it already
> > is a relatively large bit of code)
> >
> > There are other ways to get the same results since the rewrite rules for
> > a directory apply after mod_authz_svn accepted the requested path.
> > (If mod_authz_svn rejected the path, the rewrite engine never even gets
> > a chance to run)
> >
> > For example, here is the .htaccess I use and one previous version:
> > (note - in my setup, this goes into the "/" directory of the web server)
> >
> > http://svn.sinz.com/svn/Insurrection/trunk/.htaccess?Insurrection=get&r=221
> > http://svn.sinz.com/svn/Insurrection/trunk/.htaccess?Insurrection=get&r=220
> >
> > Now, this is a repository that requires user authentication for read access:
> >
> > http://svn.sinz.com/svn/example2/trunk/fold/fold.html?Insurrection=get&r=6
> >
> > (Sorry, no public user name defined, but this is mod_authz_svn doing the
> > authentication, just like it does for the SVN access rights)
> >
> > Note that there is no way to secure a revision number itself. So if you have
> > access to the file, you have access to its history.
> >
> > The reason for the get operation is that I also use this to provide access
> > controls on the log files, diffs, etc., that Insurrection provides the web
> > interface for. It makes for a really nice interface to let mod_authz_svn
> > do all of the authentication.
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Phillip Susi <ps...@cfl.rr.com>.
I find that you can access older revisions via web browser by using URLs
like this:
https://server/svn/!svn/bc/123 where 123 is the revision number you seek.
I'm not sure why this isn't documented in the SVN book. According to
the DelvtaV standard, the URL syntax used to differentiate between
versions is left up to the server, and the client needs to use special
requests to ask the server what URL to use to access specific versions.
I looked at apache's access log though and found that svn was using
URLs like the above, and gave it a try and it worked.
Michael Sinz wrote:
> solo turn wrote:
>
>>hi,
>>
>>why is it not possible to extend webdav or deltav standard to also
>>have a means of retrieving a version/revision of a resource like:
>>http://svn.collab.net/repos/svn/trunk/README?rev=1000
>>which would allow normal apache access control on the url?
>
>
> Actually, using the rewrite trick that I have in the Insurrection tools,
> this sort of works. That is, the mod_authz_svn does all of the URL
> access controls because the access controls are handled before the
> .htaccess rewrite rules run.
>
>
>>is there any disadvantage in this approach i am not able to see?
>
>
> Other than making mod_dav_svn be more than what it is (and it already
> is a relatively large bit of code)
>
> There are other ways to get the same results since the rewrite rules for
> a directory apply after mod_authz_svn accepted the requested path.
> (If mod_authz_svn rejected the path, the rewrite engine never even gets
> a chance to run)
>
> For example, here is the .htaccess I use and one previous version:
> (note - in my setup, this goes into the "/" directory of the web server)
>
> http://svn.sinz.com/svn/Insurrection/trunk/.htaccess?Insurrection=get&r=221
> http://svn.sinz.com/svn/Insurrection/trunk/.htaccess?Insurrection=get&r=220
>
> Now, this is a repository that requires user authentication for read access:
>
> http://svn.sinz.com/svn/example2/trunk/fold/fold.html?Insurrection=get&r=6
>
> (Sorry, no public user name defined, but this is mod_authz_svn doing the
> authentication, just like it does for the SVN access rights)
>
> Note that there is no way to secure a revision number itself. So if you have
> access to the file, you have access to its history.
>
> The reason for the get operation is that I also use this to provide access
> controls on the log files, diffs, etc., that Insurrection provides the web
> interface for. It makes for a really nice interface to let mod_authz_svn
> do all of the authentication.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Older versions through http-repository browsing
Posted by Michael Sinz <Mi...@sinz.org>.
solo turn wrote:
> hi,
>
> why is it not possible to extend webdav or deltav standard to also
> have a means of retrieving a version/revision of a resource like:
> http://svn.collab.net/repos/svn/trunk/README?rev=1000
> which would allow normal apache access control on the url?
Actually, using the rewrite trick that I have in the Insurrection tools,
this sort of works. That is, the mod_authz_svn does all of the URL
access controls because the access controls are handled before the
.htaccess rewrite rules run.
> is there any disadvantage in this approach i am not able to see?
Other than making mod_dav_svn be more than what it is (and it already
is a relatively large bit of code)
There are other ways to get the same results since the rewrite rules for
a directory apply after mod_authz_svn accepted the requested path.
(If mod_authz_svn rejected the path, the rewrite engine never even gets
a chance to run)
For example, here is the .htaccess I use and one previous version:
(note - in my setup, this goes into the "/" directory of the web server)
http://svn.sinz.com/svn/Insurrection/trunk/.htaccess?Insurrection=get&r=221
http://svn.sinz.com/svn/Insurrection/trunk/.htaccess?Insurrection=get&r=220
Now, this is a repository that requires user authentication for read access:
http://svn.sinz.com/svn/example2/trunk/fold/fold.html?Insurrection=get&r=6
(Sorry, no public user name defined, but this is mod_authz_svn doing the
authentication, just like it does for the SVN access rights)
Note that there is no way to secure a revision number itself. So if you have
access to the file, you have access to its history.
The reason for the get operation is that I also use this to provide access
controls on the log files, diffs, etc., that Insurrection provides the web
interface for. It makes for a really nice interface to let mod_authz_svn
do all of the authentication.
--
Michael Sinz Technology and Engineering Director/Consultant
"Starting Startups" mailto:michael.sinz@sinz.org
My place on the web http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org