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
Hi,
This won't work if you receive more than one snapshot, each one derived
from the previous one (btrfs send -e snap1 snap2 snap3 snap4). You
would always use the first one as the parent, not the predecessor.
That's implemented differently for the -p option in
On Sun, 26 Apr 2015 12:12:45 +0200, Lauri Võsandi wrote:
This patch adds command-line flag -p to btrfs receive
which makes it possible to disable automatic parent
search for incremental snapshots and use explicitly
specified path instead.
Signed-off-by: Lauri Võsandi lauri.vosa...@gmail.com
On 4/27/2015 11:23 AM, lauri wrote:
Hi,
This won't work if you receive more than one snapshot, each one derived
from the previous one (btrfs send -e snap1 snap2 snap3 snap4). You
would always use the first one as the parent, not the predecessor.
That's implemented differently for the -p option
This patch adds command-line flag -p to btrfs receive
which makes it possible to disable automatic parent
search for incremental snapshots and use explicitly
specified path instead.
Signed-off-by: Lauri Võsandi lauri.vosa...@gmail.com
---
cmds-receive.c | 34 ++
1
On Sun, Apr 26, 2015 at 12:12:45PM +0200, Lauri Võsandi wrote:
This patch adds command-line flag -p to btrfs receive
which makes it possible to disable automatic parent
search for incremental snapshots and use explicitly
specified path instead.
As I said when we discussed this on IRC, I
Hi,
Subvol A on source side: (A, -)
Send this to A' on target side: (A', A)
Send this back to A'' on source side: (A'', A) -- Note the A here, not A'
I also think your approach is the real solution to the problem, but as
some pointed out on IRC this changes the behaviour of btrfs receive
and
