Tangential question about bzr concepts

[Andrew S. Townley]

On Fri, 2006-03-31 at 10:43, Martin Pool wrote:
> On 29 Mar 2006, "Andrew S. Townley" <andrew.townley at bearingpoint.com> wrote:
> > 
> > Hi Guys,
> > 
> > This isn't specifically a bzr question, but I'm trying to see if bzr (or
> > parts thereof) could be used as the solution.
> > 
> > If you were prepared to accept the risk of not keeping version history,
> > could the logic in bzr as a distributed VCS be used to assist in keeping
> > peer-to-peer replicas (say, of a filesystem) in sync.  Maybe there's
> > something to do this already, but rsync doesn't merge changes to files.
> > 
> > What I want is that if I've made a change to a text file (maybe on both
> > systems), those changes would be merged and propagated to all of the
> > hosts, meaning that I wouldn't really lose any data.  I know this
> > problem has been solved for databases with multi-master capabilities,
> > but I was wondering if something like the merge stuff in bzr would
> > assist in doing it for filesystems.
> > 
> > This was just something I was wondering about, and I know it isn't
> > directly related, but thanks for the tolerance :)
> > 
> > Thanks in advance,
> 
> You can use bzr to do this.  
> 
> I'm not sure what you mean by "accept the risk of not keeping version
> history".  If you mean "I want to merge without keeping version history"
> then it's not really in our scope, and not keeping any history will
> restrict the kind of merges you're able to do.  If you strongly want to
> not keep history then you might like to look at Unison, Coda, etc.
> (Well, they do keep history, but of a more restricted type.)

Thanks Martin.  However, my unclear comment was really to do with the
space requirements.  I looked at Coda, but that isn't really what I want
because it implies there is only one repository.  Why I was kind of
"navel gazing" about bzr was so that I could isolate, say a directory
tree, and then have that tree able to be sensibly merged in either
direction from one client to two different servers.

I know it's possible if I use bzr as is, but the problem I have is the
disk space usage for the revisions.  If I have a bunch of text files
(e.g. source code), it isn't really that big of a deal, but where you're
talking about managing word or other binary documents some of which are
20M a piece, it can quickly eat into your usable filesystem space.  I
know bzr won't help me with the "inside merge", but at least something
like bzr would keep things up to date.  In this case, there's no need
(and in fact, I don't want) to have simply cached versions between the
client and the server.

Anyway, like I said, I'm just thinking about the problem because I'm
having some trouble managing some occasionally connected machines that
effectively have two "homes" or none at all, depending on your point of
view.  I don't know if I'm going to tackle the problem or not as yet,
but if it was something I could do reasonably easily, then I might
seriously consider devoting some time to it.

Maybe it was a dead end, but was just wondering.

Thanks for your time,

ast
-- 
Join me in Dubrovnik, Croatia on May 8-10th when I will be speaking at
InfoSeCon 2006.  For more information, see www.infosecon.org.

***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************