Re: Me again, csetpruning

Email is a little long; maybe you'll want to skip to
the summery below ;-)

Rick Smith wrote:
[...]

Firstly; thanks for the detailed replies everyone, I havent solved
my problem but appriciate the attention (makes a HUGE difference
in my progress).

> Here's something you can do to ease some pain, but has some pain:
>
> make a copy of the current state of all the binary files.
> bk rm the binary files
> bk new the copies of the binary files
> clone the repo
> csetprune the deleted files
> have people do new work on a clone of the csetpruned repository

Ok, so at this point we create a new repo without the history
that is usable and smaller...

> There will be some people who will be finishing up some work
> in an old repo.
> They will pull and get a conflict that they modified a deleted file.
> After the resolve, then need to get the state of the deleted binary
> file and make a delta on the new binary file location.

Hmmm; dont really care about those people, there can never be more
then like 12 of them so I can tell them to clone and apply their work
on the new repo.

> After they push, a csetprune can be run on a clone, and that
> repo can be pulled and merged with the other csetpruned repos.

I see, this is the "one-way bridge" you speak of... I could save
myself some typeing by just creating a new bk repo and import all
the files from the old big repo by hand... and lose that one way
bridge; all I need is a one-way bridge that goes the other way :-/

This is what I'm thinking I'll do to somewhat address the problem;
we currently use a heirarchy of repo's as described in the chart below,
minus the HISTORY repo, here would be my plan:

  o Make HISTORY an identical parent of STABLE via clone/reparent
  o Routinely strip all history from STABLE in the way you described
    I guess after this point 'user@host ~/path/HISTORY$ bk pull STABLE'
    is broken due to incompatabilities (or maybe I'll just create
    new repos for that)
  o Since we can safely assume that the relationship between
    STABLE/HISTORY is always incremental (i.e. never any merges or
    anything; patches apply one on top of the other), then we can
    somehow generate patches to HISTORY every time we nuke the
    history in STABLE.

It would really be great if I could somehow manually patch HISTORY
as a bk repo and tell myself "I cant really pull & push from it
now; but when our buddies implement binpool or whatever; we'll be
able to revive this repo"... untill then all that I've noticed that
breaks is "bk pull/push"; cloning the repo worked (so I could still
reproduce a working copy from a bitkeeper TAG... I hope)

If I cant do that... I'll have to just save tarballs of STABLE in
a directory called HISTORY and name them by the date we stripped
history from STABLE; which would still be usefull... but no so
much fun :-/

Summery:
========
    o Will I eventually be able to revive such a repo with later
      versions of BitKeeper and what would be the ETA (Larry said
      about 6 months for binpool; but I dont know if that would
      include the revival of broken repos) ?
    o Is it a safe assumption that with an huge repo like that;
      I can still use bk clone -rTAG to reproduce working builds ?
    o Any concievable way I that I can tack changesets onto HISTORY
      from STABLE without using bk push/pull; would bk send/recieve
      work for this even though the repositories dont exacly match
      anymore ?

==========================================
         +---------+
         | HISTORY |
         +---------+
              |
         +--------+
         | STABLE |
         +--------+
              |
       +-------------+
       | INTEGRATION |
       +-------------+
         /          \
  +-----------+  +-----------+
  | PROJECT A |  | PROJECT B |
  +-----------+  +-----------+
      |
+------------+
| Joe's copy |
+------------+
==========================================

Cheers,
                            -Tristan