Branching

[lanwatch]

Hi all,

I am rather new to bup, I discovered it while searching for a file

management tool that would:

1. work under linux and windows

2. be space and network-efficient

3. be mindful of open files (snapshot first, copy later)

4. support versioning a-la git (merges are a difficult topic with

   binaries)

I think bup is great for 1 and 2. For 3 I found bup-cron, which seems to

work with LVM snapshots (linux) and VSS (windows).

For 4, I believe given the underlying git repo that bup creates, I could

use git cmdline to "play" with branches and create a new branch (branch1

say) for the latest. Then save a few modifications with bup, that would

keep updating its latest branch as usual. Later another user would be

able to restore from that branch1, save some modifications, and

(hopefully) that would create a parallel branch.

Not sure I explained myself well. Anyway, before using git to try to

hack around this, I was wondering if there a preferred way of doing

branching with bup itself or some dedicated tool/script. Maybe

someone has previous experience?

Thanks!

[Greg Troxel]

lanwatch <lanw...@gmail.com> writes:

> 1. work under linux and windows

and more

> 2. be space and network-efficient

ok here

> 3. be mindful of open files (snapshot first, copy later)

just reads the filesystem, but you can do this as a wrapper.

> 4. support versioning a-la git (merges are a difficult topic with
> binaries)

I don't follow what you want.

> I think bup is great for 1 and 2. For 3 I found bup-cron, which seems to
> work with LVM snapshots (linux) and VSS (windows).

You sound like you are on the right track here.

> For 4, I believe given the underlying git repo that bup creates, I could
> use git cmdline to "play" with branches and create a new branch (branch1
> say) for the latest. Then save a few modifications with bup, that would
> keep updating its latest branch as usual. Later another user would be
> able to restore from that branch1, save some modifications, and
> (hopefully) that would create a parallel branch.

The norm is that the "save name" is a branch, refs/heads/foo, and each
backup is a commit whose first parent is the previous one.

As for someone else, they'd need a new save name and thus would not have
the ancestry, but many of the objects might match -- IF you are careful
about matadata and especialy ctime (don't remember if ctime is stored).

> Not sure I explained myself well. Anyway, before using git to try to
> hack around this, I was wondering if there a preferred way of doing
> branching with bup itself or some dedicated tool/script. Maybe
> someone has previous experience?

The real question is do you want backups, or do you want a VCS?
It sounds like you think you want backups but really you want a VCS :-)

[Greg Troxel]

Fran Martínez <fran...@gmail.com> writes:

> Then I would add a branch name somewhere "in-between", thus
> effectively creating another "save name" in the middle of the history,
> restore that, and keep saving versions from there. Check performance
> of operations and deduplication efficiency.
>
> Now you will probably tell me why that is a bad idea? :)
>
> Are you aware of better OSS alternatives?

I expect that you will get good dedup. However, the equivalent of "git
log" and "git diff" won't really do what I think you will end up
wanting.

But please do write up your results and publish it and send a pointer
here.

For a VCS with large contents, I would look at git-annex, but I don't
really have that problem so I haven't.