Re: Me again, csetpruning

On Wed, Mar 01, 2006 at 11:28:25AM -0500, Tristan Van Berkom wrote:
> So for a temporary solution... I'll:
>     o Copy my repo onto a backup so as to keep the history somewhere
>     o Run csetprune to remove all delta's on binary files that are
>       not the `head' delta.
> I've been toying with 'bk prs' and its doc so as to generate the
> list of keys to pass to csetprune (in order to prune just the history)
> 
> so far I have:  bk -r prs -hr+ -nd'$if(:ENC:=binary){:ROOTKEY:}'
> 
> which will fetch me all the deltas for binary files... how do
> I specify that I want all deltas except the latest `HEAD' delta ?

As Larry mentioned, this won't work.
Csetprune does not prune history, it prunes files.
The repository that results can not communicate with clones of
the repo before the csetprune.  There is a one way bridge that
can be built from old to new by doing a csetprune on a clone of
old each time a cset wants to be moved.

Csetprune is best used when splitting a repository in two, and
when deleting the BitKeeper/deleted directory.

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

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.

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

See -S and -k options to csetprune for allowing this to work.

Once people are using a csetpruned version, then it will work
as normal -- getting slower over time as you've found now.

Rick

> Cheers,
>                             -Tristan
> PS:
> Also stumbled on this:
> http://db.bitkeeper.com/cgi-bin/view.cgi?id=2005-01-12-004
> 
> I dont know about the site permissions but maybe I should (or
> someone with permission should)... write this handy info in
> as a workaround for other concerned googler's benefit ?
> 
> -- 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing on usenet and in e-mail?