[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [REJECT: merge-robertc-2] odd cachedrev/mirror chan
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] Re: [REJECT: merge-robertc-2] odd cachedrev/mirror change |
Date: |
Wed, 5 May 2004 17:15:48 -0700 (PDT) |
> From: Robert Collins <address@hidden>
> On Thu, 2004-05-06 at 09:44, Tom Lord wrote:
> > > From: Robert Collins <address@hidden>
> > > > Could you please write a quick explanation rather than having
me =
> try
> > > > to reverse engineer it?
> > > 'tla archive-mirror archive revision' now special cases handling
of
> > > cacherevs, and syncronises the source state to the mirror -
adding =
> or
> > > removing as needed.
> > > This is one solution to 'how do I get a good cacherev of revision
X=
> '
> > > onto my mirror AFTER the revision itself is there, without any
bogo=
> sity
> > > like checking this on /every revision/.
> >=20
> > That's what I gathered. It seems rather random. It's surprising to
> > see this special case behavior. Assuming I wanted to sink with a
> > mirror source at all, I don't see any good reason to do it revision by
> > revision. Assuming that a mirror source was in a different cachedrev
> > state that I wanted to emulate, copying from the mirror state isn't
> > obviously the right way to do it.
> Suggestions welcome. This code works for me :}. Syncing an entire mirror
> (or even version) is much more expensive, and the general case of 'push
> new changesets' shouldn't have to review every revision IMO.
rsync plus symlink swizzling?
Really, I don't have a clear idea of what problem you are trying to
solve -- perhaps you could explain. I can see interactions with
signatures and mirrored cachedrevs. I can see trade-offs between
freshly computing cachedrevs and copying them. I can see how those
two areas play off one another.
There's no clearly right thing to do absent any specific problem to
solve.
-t