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
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 optio
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
> git://git.kernel.org/pub
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
> ---
> cmds-rec
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
a
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
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
---
cmds-receive.c | 34 ++
1 file changed, 26 insert
