Martin, I dont think this is a bug.
PUT /files/a.xml
VERSION-CONTROL /files/a.xml
---> /files/a.xml is now associated with /history/1
DELETE /files/a.xml
---> /history/1 has not been deleted
PUT /files/a.xml
---> /files/a.xml is not under version control
VERSION-CONTROL /files/a.xml
---> /files/a.xml is now associated with /history/2 (!!)
That all is correct behaviour according to DeltaV.
If your intention was to resurrect a.xml in the same history, instead of the second
PUT you would use a special form of the VERSION-CONTROL request (see RFC3253, 6.7):
DELETE /files/a.xml
---> /history/1 has not been deleted
VERSION-CONTROL /files/a.xml (using version /history/1/1.0)
---> /files/a.xml is now associated with /history/1 (!!)
Regards,
Peter
> -----Original Message-----
> From: news [mailto:[EMAIL PROTECTED] Behalf Of Martin Holz
> Sent: Monday, March 29, 2004 18:39
> To: [EMAIL PROTECTED]
> Subject: Re: How about RC1?
>
>
> Oliver Zeigermann <[EMAIL PROTECTED]> writes:
>
> > Martin Holz wrote:
> >
> > > Oliver Zeigermann <[EMAIL PROTECTED]> writes:
> > >
> >
> > >>Martin Holz wrote:
> > > See http://thread.gmane.org/gmane.comp.jakarta.slide.user/2366
> > > 2) AFAIK the connection to history is lost if a resource
> is deleted.
> >
> > I have checked this and - no - the history is not deleted...
>
> I should have been clearer. If you do
>
> PUT
> serveral PUT,CHECKIN
> REPORT
> DELETE
> PUT
> REPORT
>
> the new resource will not know, that there was a resource at
> the same URI
> before. The information is still in history and can be retrived doing
> a search/propfind over the /history tree. But you will not know it
> from the resource itself.
>
> Martin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
