[Gnu-arch-users] Re: [REJECT: merge-robertc-2] odd cachedrev/mirror change

[Tom Lord]

    > 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