Re: COPY collection to an existing resource
Geoffrey M Clemm <[email protected]> Thu, 13 Jul 2006 08:44:24 -0400
| Newsgroups | gmane.ietf.deltav |
|---|---|
| Message-ID | <OF0CD84BC5.F8B200EE-ON852571AA.0045D4A1-852571AA.0045FB96@us.ibm.com> |
This is a multipart message in MIME format. --=_alternative 0045FAE0852571AA_= Content-Type: text/plain; charset="US-ASCII" Yes, and note that a client can also just DELETE the target before requesting the COPY, in which case a fresh set of resources would be created at the destination (each with a new version history, if the server automatically puts new resources under version control). Cheers, Geof Werner wrote on 07/13/2006 05:53:37 AM: > > In other words, the position is taken that when a user > copies a collection to an existing destination, both are > likely to be related to the user. Otherwise strange > version histories would result for internal members that > happen to coincide. This position seems reasonable. > > There is a practical consequence for the user, however. > Since the operation is recursive, the user has to be aware > of the internal members that coincide at any depth and > make sure that either they are checked out or that their > "auto-version" property is set properly. It is also > necessary that all subcollections at the destination are > checked out or have the appropriate auto-version property. --=_alternative 0045FAE0852571AA_= Content-Type: text/html; charset="US-ASCII" <br><tt><font size=2>Yes, and note that a client can also just DELETE the target before requesting the COPY, in which case a fresh set of resources would be created at the destination (each with a new version history, if the server automatically puts new resources under version control).</font></tt> <br> <br><tt><font size=2>Cheers,</font></tt> <br><tt><font size=2>Geof</font></tt> <br> <br><tt><font size=2>Werner wrote on 07/13/2006 05:53:37 AM:<br> <br> > <br> > In other words, the position is taken that when a user<br> > copies a collection to an existing destination, both are<br> > likely to be related to the user. Otherwise strange<br> > version histories would result for internal members that<br> > happen to coincide. This position seems reasonable.<br> > <br> > There is a practical consequence for the user, however.<br> > Since the operation is recursive, the user has to be aware<br> > of the internal members that coincide at any depth and<br> > make sure that either they are checked out or that their<br> > "auto-version" property is set properly. It is also<br> > necessary that all subcollections at the destination are<br> > checked out or have the appropriate auto-version property.<br> <br> </font></tt> --=_alternative 0045FAE0852571AA_=--