Hi, > My argument is that having this option present will mean that > people will use it. Getting send/receive right is hard enough as it is > without giving someone an option which can completely screw things up > in *most* cases.
I agree that providing workarounds like this is not nice, however considering the users who are already stuck with the UUID-s of current architecture should be provided a way to get back on the track with better implementation :) > The chain rule can (must) be done on the send side. The reference rule > means that we need both r1 and u1 to be available on the receiving > side. I haven't checked, but this will probably involve a change to > the stream format to send r1. I've also concluded the real solution involves bundling both subvolume UUID and received UUID with the btrfs stream. This implies btrfs send stream format change and if I've understood correctly involves kernel changes as btrfs stream is generated in kernelspace. > The other thing that we don't support at all is merging changes > from divergent snapshots. i.e. snapshot A to B and C, modify both B > and C, and then later try to merge B and C into D. (Possibly with > additional sends between all of those stages). This gets into issues > of semantic merging. I feel entirely justified in telling anyone who > wants to implement that kind of workflow that it's out of scope for > send/receive, and referring them to a distributed revision control > system like git. I've never suggested merges, when I mentioned Git-like workflow I was referring to simply push/pull. Obviously implementing merge is out of the scope of any filesystem ;) -- Lauri Võsandi tel: +372 53329412 e-mail: lauri.vosa...@gmail.com blog: http://lauri.vosandi.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
