You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Shlomi Fish <sh...@iglu.org.il> on 2004/04/08 10:47:38 UTC
ra_dav Protocol for the trace_old_file_location Function
Hi!
The purpose of this E-mail is to suggest a protocol for the
trace_old_file_location function over WebDAV/DeltaV (to be implemented as a
client in libsvn_ra_dav and as a server in mod_dav_svn). The function will
use a REPORT request, with the following customized XML Body:
Wrapping XML Tag is <S:trace-old-node-location>.[1] It contains the tags:
1. <D:source>. This contains a <D:href> that contains the URL that needs to be
traced.
2. <S:peg-revision>. This contains the peg revision.
3. <S:past-revision>. This contains the past revision.
For example, a request to trace the old location at revision 5 of URL
http://localhost/svn/repos/myfile.txt at revision 28 will look like this:
<<<
<S:trace-old-node-url xmlns:S=\"[SVN_XML_NAMESPACE]" xmlns:D="DAV:">
<D:source><D:href>http://localhost/svn/repos/myfile.txt</D:href></D:source>
<S:peg-revision>28</S:peg-revision>
<S:past-revision>5/S:past-revision>
</S:trace-old-node-url>
>>>
In return we will get upon successful completion of operation the following
response:
<<<
<S:trace-old-node-url-report xmlns...>
<S:past-url><D:href>http://localhost/svn/repos/my-old-file.txt</D:href></S:past-url>
</S:trace-old-node-url-report>
>>>
Or a DAV error if the operation was not successful.
Regards,
Shlomi Fish
[1] - "S:" is the subversion namespace. "D:" is the WebDAV/DeltaV namespace.
---------------------------------------------------------------------
Shlomi Fish shlomif@iglu.org.il
Homepage: http://shlomif.il.eu.org/
Quidquid latine dictum sit, altum viditur.
[Whatever is said in Latin sounds profound.]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_dav Protocol for the trace_old_file_location Function
Posted by Branko Čibej <br...@xbc.nu>.
Shlomi Fish wrote:
>On Thursday 08 April 2004 16:30, C. Michael Pilato wrote:
>
>
>>Shlomi Fish <sh...@iglu.org.il> writes:
>>
>>
>>>Hi!
>>>
>>>The purpose of this E-mail is to suggest a protocol for the
>>>trace_old_file_location function over WebDAV/DeltaV (to be
>>>implemented as a client in libsvn_ra_dav and as a server in
>>>mod_dav_svn). The function will use a REPORT request, with the
>>>following customized XML Body:
>>>
>>>
>>Adamently opposed to "trace_old_file_location". Don't box us into
>>this one operation, please. I'd much rather have the RA interface
>>called just RA->get_locations()
>>
>>
>>
>
>Just "get_locations"? This is too generic a name and could mean all sort of
>things. How about "get_past_locations"?
>
>
Let me just say again at this point that it should not be only about
past locations. Now if people want to have two different APIs instead of
one in the RA layer, one for past only and one generic -- well, I'll get
the last laugh :-)
But it absolutely does not make sense to have _two_ different custom
reports for what is essentially one family of operations.
So yes, get_locations is fine.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_dav Protocol for the trace_old_file_location Function
Posted by Shlomi Fish <sh...@iglu.org.il>.
On Thursday 08 April 2004 16:30, C. Michael Pilato wrote:
> Shlomi Fish <sh...@iglu.org.il> writes:
> > Hi!
> >
> > The purpose of this E-mail is to suggest a protocol for the
> > trace_old_file_location function over WebDAV/DeltaV (to be
> > implemented as a client in libsvn_ra_dav and as a server in
> > mod_dav_svn). The function will use a REPORT request, with the
> > following customized XML Body:
>
> Adamently opposed to "trace_old_file_location". Don't box us into
> this one operation, please. I'd much rather have the RA interface
> called just RA->get_locations()
>
Just "get_locations"? This is too generic a name and could mean all sort of
things. How about "get_past_locations"?
> svn_error_t *
> get_locations (apr_hash_t **locations,
> const char *path,
> svn_revnum_t peg_revision,
> apr_array_header_t *location_revisions,
> apr_pool_t *pool);
>
> Allow folks to pass a path, a peg revision, and a set of location
> revisions. The return hash maps those same location revisions to
> the location paths.
>
OK. Should the location_revisions be sorted before calling the function?
Otherwise, the implementation would have to sort them.
> DAV REPORT request protocol would look similar to what you suggested,
> save for <S:get-locations> instead of <S:trace-old-file-location>,
> <S:location-revision> instead of <S:past-revision>, and the ability
> to specify many <S:location-revision> tags.
>
I still don't think it is wise to simply call it "location-revision" or
"get-locations".
> DAV REPORT response protocol would be something like:
>
> <S:get-location-report xmlns...>
> <S:location>
> <S:location-revision>45</S:location-revision>
> <D:href>http://localhost/svn/repos/my-old-file.txt</D:href>
> </S:location>
> <S:location>
> <S:location-revision>56</S:location-revision>
> <D:href>http://localhost/svn/repos/my-other-old-file.txt</D:href>
> </S:location>
> ...
> </S:get-location-report>
>
> If the PATH@PEG-REVISION doesn't exist, you get a 404. Otherwise,
> revisions in which the path didn't exist simply don't show up in the
> response.
>
Sounds fair.
Regards,
Shlomi Fish
---------------------------------------------------------------------
Shlomi Fish shlomif@iglu.org.il
Homepage: http://shlomif.il.eu.org/
Quidquid latine dictum sit, altum viditur.
[Whatever is said in Latin sounds profound.]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: ra_dav Protocol for the trace_old_file_location Function
Posted by "C. Michael Pilato" <cm...@collab.net>.
Shlomi Fish <sh...@iglu.org.il> writes:
> Hi!
>
> The purpose of this E-mail is to suggest a protocol for the
> trace_old_file_location function over WebDAV/DeltaV (to be
> implemented as a client in libsvn_ra_dav and as a server in
> mod_dav_svn). The function will use a REPORT request, with the
> following customized XML Body:
Adamently opposed to "trace_old_file_location". Don't box us into
this one operation, please. I'd much rather have the RA interface
called just RA->get_locations()
svn_error_t *
get_locations (apr_hash_t **locations,
const char *path,
svn_revnum_t peg_revision,
apr_array_header_t *location_revisions,
apr_pool_t *pool);
Allow folks to pass a path, a peg revision, and a set of location
revisions. The return hash maps those same location revisions to
the location paths.
DAV REPORT request protocol would look similar to what you suggested,
save for <S:get-locations> instead of <S:trace-old-file-location>,
<S:location-revision> instead of <S:past-revision>, and the ability
to specify many <S:location-revision> tags.
DAV REPORT response protocol would be something like:
<S:get-location-report xmlns...>
<S:location>
<S:location-revision>45</S:location-revision>
<D:href>http://localhost/svn/repos/my-old-file.txt</D:href>
</S:location>
<S:location>
<S:location-revision>56</S:location-revision>
<D:href>http://localhost/svn/repos/my-other-old-file.txt</D:href>
</S:location>
...
</S:get-location-report>
If the PATH@PEG-REVISION doesn't exist, you get a 404. Otherwise,
revisions in which the path didn't exist simply don't show up in the
response.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org