Re: Re: [rfc] git: combo-blobs

[Petr Baudis]

Dear diary, on Mon, Apr 11, 2005 at 08:13:19PM CEST, I got a letter
where Chris Wedgwood <cw@xxxxxxxx> told me that...
> On Mon, Apr 11, 2005 at 09:01:51AM -0700, Linus Torvalds wrote:
> 
> > I disagree. Yes, the thing is designed to be replicated, so most of
> > the time the easiest thing to do is to just rsync with another copy.
> 
> It's not clear how any of this is going to give me something like
> 
>      bk changes -R
> 
> or
>      bk changes -L
> 
> functionality.  I'm guessing I will have to sync locally and check
> between two trees in those cases?  Or at least sync enough metadata as
> to make this possible...  but not the entire tree right?

Checking "what will be transferred when I push" doesn't sound hard - the
push itself is not too trivial, but solvable. Perhaps even by pure
rsync, if you won't support updating tracked trees (does not sound
overwhelmingly useful anyway).

Checking "what will be transferred if I pull" is much worse. Perhaps you
could make a parallel objects repository, fetch all the newer commit and
tree metadata there, and then do diff-tree. I think you need something
smarter than rsync for that, though.

[git-pasky] As long as you are not pulling from a tracked branch, the
worst what can happen is that the enemy will trick you to pulling some
terabytes of data. Or overwrite existing objects with garbage, but
--ignore-existing would solve that trivially.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/