+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.
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.
Thanks,
Chathura
Sanjiva Weerawarana wrote:
[EMAIL PROTECTED] wrote:
+1 for this. And I have something to clarify as well , how we are
going to
handle the versions in the case. Are we going to consider this as delete
and add (with old versions) to new location or just delete and add as a
new one.
I think it needs to be a single operation. That way you can undo an mv
and get back to the same state in one operation. Otherwise you have
the option of getting to intermediate states that did not exist in
reality. That can't be right.
Sanjiva.
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
