Re: [Gnu-arch-users] Why we might use subversion instead of arch.

[Pierce T . Wetter III]

> >  The main rough edge I see is that I think local-mirrors of a remote
> > archive should allow you to commit, with the changes propagating 
> > upwards to
> > the source. Especially a greedy mirror.
>
> I agree, `write-through' mirrors would be a fine feature; I'd probably 
> use
> mirroring more if it were available.
>
> I suppose the simplest version would be simply keeping two archive 
> paths for
> each archive name, saying `use path A for commits, and path B for 
> everything
> else'.

 Since tla already has an idea of an "ancestor" archive, perhaps it 
would make sense for things to just use that?

 Because really, if I'm doing this right, without mirroring, I could 
have the following chain:


   master archive  (we'll call this "master")
           local child of master archive (we'll call this "cache")
                main work archive, child of "cache
                     ( we'll call it "pierce")


 Without mirroring, I could do:

  tla update -A "cache"      (copies master down to cache)
  tla update -A "pierce"     (copies cache to pierce)

  tla commit -A "pierce"     (copies changes to cache)
  tla commit -A "cache"      (copies cache to master)

  Except what we really want is to be able to setup "cache" so that all 
we have to do is do:

  tla update -A "pierce"      (copies master down to cache, then cache 
to pierce)

  tla commit -A "pierce"     (copies changes to cache, then cache to 
master)

  The update is probably pretty easy (I think that's what greedy 
mirrors do already?). The commit is harder, because you really want to 
do with conflict resolution between pierce & master, not pierce & 
cache. Perhaps as a first draft though, a transparent cache could just 
forward the commit automatically to its parent?

  Pierce