Chathura C. Ekanayake wrote:
+1 for the proposal. I think we can do this in single operation with the
current versioning model.
In the "rename" operation, we can change the resource state to "RENAMED"
or "MOVED", create a new version and add the new version's dependency to
the new parent location. Therefore, browsing previous versions and
restoring to old versions should work. But there are some tricky
scenarios that we have to consider:
c1/r1 is moved to c1/c2/r1. Then what happens if a new resource with the
name r1 is added to c1.
Nothing special .. this is like the case when you delete r1 from c1 and
then add a new resource called r1 to it. Its simply a new version of c1.
c3/c4/r5 is moved to c3/r5. Then c4 is deleted. What happens if we want
to restore r5 to previous version (c3/c4/r5). - I think we should inform
that c4 is deleted and fail the operation.
Isn't the concept wrong? That is, the presence of r5 as a sub resource of
c4 etc. was in a version of c4. So to get back to that, you'd need to go
to a version in the world where c4 exists. So when you look at revisions
of c3, you'll see the right version and go there.
Sanjiva.
--
Sanjiva Weerawarana, Ph.D.
Founder, Chairman & CEO; WSO2, Inc.; http://www.wso2.com/
email: [EMAIL PROTECTED]; cell: +1 650 265 8311 | +94 77 787 6880
"Oxygenating the Web Service Platform."
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
