[Bitkeeper-users] Me again, csetpruning

[Tristan Van Berkom]

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 at 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