The wc-ng approach is a database transaction that modifies the database and adds one or more workqueue items to modify the working files and directories. At least initially, there is likely to be one transaction per versioned node in the source. I suppose when we centralise it might be possible to copy the whole tree in a single transaction, but I'm not sure what the workqueue would look like.
I'm not sure how/when unversioned items get handled. Do we create workqueue items for them when adding the parent directory? Does each one get its own transaction/workqueue? Do we copy them without transactions? One of the problems before centralisation is that a copied directory cannot be fully added to the database until the directory has been created in the filesystem. We can add the directory to the database in the parent and we can put workqueue items there as well, but a directory also needs to be added to its own database. I suppose we could create the new directory before executing the transaction, but that seems to be completely at odds with the transaction/workqueue approach. It's probably better to have the transaction just add the directory in the parent database and have workqueue items that create the new directory that modify the new database. Is the current svn_wc__db_op_copy_file iterface the correct one for wc-to-wc copies? It's sensible for a repo-to-wc copy where all the source information has to be inserted into the database, but for a wc-to-wc copy that information is in the database already. Perhaps we should just pass the source path and copy all the information with a database query? Perhaps we should continue to do a dumb copy as the first step even with wc-ng? That would create a new completely unversioned tree and then one or more tranactions could modify the database(s). At the moment there is no way to restart an interrupted copy, so although the transaction/workqueue approach means that the nodes will show up as incomplete it's not clear what the user could do. -- Philip
